Is Mikrotik devices are subject to year 2038 bug ?
I ask this question because many devices running on 32 bits processors have this problem due to 32 bits time representation after 03:14:07 UTC on 19 January 2038 (all bits at 1) and I did not found such information on Mikrotik documentation.
For example, Mikrotik RB4011iGS+RM has an ARM 32bit architecture.
In addition, if the software (RouterOS) is 32 bits running on a 64 bits processor (compatibility mode), we can also have the same problem due to the software despite a 64 bits processor.

It will be fixed with a Linux kernel update.

15 years to do that

Is Mikrotik devices are subject to year 2038 bug ?

How can it have any relevance now?
The software that exists now in 15 years may no longer exist,
as indeed all new peripherals may only have 64-bit processors.
Or are you going to leave the same machine and software for more than 15 years???

Or are you going to leave the same machine and software for more than 15 years???

You'd be surprised how many Windows XP machines are STILL in use today...
XP was released in oct 2001.

Plenty of MikroTik devices are still running that we sold in 2008.

the year 2000 bug is still fresh in the minds of many IT managers. It cost billions to fix, and now many big IT departments' specifications logically state that any hardware/software delivered must be year 2038 bug free.
If you think that all IT hardware/software will be replaced after 5 or 10 years, then you lack industrial experience. Take a look at the system that manages the New York City subway, for example...

Plenty of MikroTik devices are still running that we sold in 2008.

Many MikroTik devices that we sold in 2008 are still in use. Sure, and I have a lot of them, even from 2007 when I opened the WISP, but that's not the point,
I DON'T STILL USE THE ROUTEROS VERSION 2 or 3 PRESENT ON THAT OLD BOARDS!!!
(all the mipsLe and old wifi with only-g, only-a or single chain, are disposed, and the rest that is still used are now running RouterOS 6.48.7)

Plenty of MikroTik devices are still running that we sold in 2008.

Many MikroTik devices that we sold in 2008 are still in use. Sure, and I have a lot of them, even from 2007 when I opened the WISP, but that's not the point,
I DON'T STILL USE THE ROUTEROS VERSION 2 or 3 PRESENT ON THAT OLD BOARDS!!!

I agree with you!
But even though we're using RouterOS 7.10 today, I'm sure there are parts of the source code or libraries used in the RouterOS version that haven't changed since RouterOS 2.00, and that's normal.
The question is about the year 2038 bug on Mikrotik systems sold today. If this problem exists today but is expected to be resolved by a future version of RouterOS (I can understand that), will this new version work on all Mikrotik devices or only on 64-bit processor devices due to the limitations of 32-bit processors that caused the 2038 "bug"?

It is a question to rightfully ask. It is not really practical for "us users" to test if there is any issue with this, that will have to be answered by MikroTik after a study of their code.
(of course you could set the clock to a date/time of jan 19th, 2038 and wait and see if it "explodes", but when it does not obviously do that it is no guarantee that all is OK)

Note that the whole issue has NOTHING to do with having a 32-bit or 64-bit processor, but ONLY with the way the code is written and compiled.
When the problem was introduced back in the seventies, by having a system time in "seconds since jan 1st, 1970" in a 32-bit variable, processors were still 16-bit.
It is perfectly possible to maintain a 64-bit variable on a 32-bit processor. It will be EASIER on a 64-bit processor at low level, but that is not visible to the C programmer, only to an assembly language programmer.
And having a 64-bit processor in itself will not resolve the issue when the variables used to maintain time and date are still declared as 32 bits!
So there has to be a code review to know that.

It will be fixed with a Linux kernel update.

Actually, no. It requires a kernel update but that has been done already. For a complete fix it has to be updated in user code as well.

OMG ... no more comments

OMG ... no more comments
Chat.PNG

If you trust OpenAI for such questions, you'll be very disapointed!
And that does not help to answer the question...

For the people who believe that having a 64 bit processor will solve everything by magic:
Today I checked if the longstanding problem in "IP->Traffic Flow" that the byte count of connections is reported in a 32-bit variable has now been fixed, using RouterOS v7 on a CCR2004 (ARM64 processor).
See the topic viewtopic.php?t=102549

The sad situation is that even 7 years after "they will look into this" and after upgrade of v6 to v7 and new hardware with 64-bit processor, this issue has NOT been fixed!
So don't assume that time_t related issues will fix themselves within 7 years.

The Y2K38 problem will be serious and nothing like the mostly non-issue Y2K occurrence. As pe1chl stated, it is a software compiler and/or user code issue. A lot of code declares memory space with an int or time_t variable which allocates a 32-bit signed time representation. When that integer overflows a segfault will take place actually causing the application to fail, hang, or take down the system all together depending on how things are connected to each other.

Correction: a segfault can take place based on how the software responds. Seen it happen here in testing.

Well, dates aren't heavily used in RouterOS.

And date in ROS is just milliseconds since 1/1/1970. So all that be need in future is new epoch is used, >1970 and still fit in 32-bits. GPS rolls its epoch more often without disaster. Party like it's 1999!

When that integer overflows a segfault will take place actually causing the application to fail, hang, or take down the system all together depending on how things are connected to each other.

No, an integer overflow will not trigger a segfault. The integer value will just wrap around, and the date will be a strange value in the past.
Indeed the result of that is that things may fail, especially in areas like certificates that have a "not valid before" date.

Well, dates aren't heavily used in RouterOS.

What about certificates?

When that integer overflows a segfault will take place actually causing the application to fail, hang, or take down the system all together depending on how things are connected to each other.

Not it won't. What utter rubbish. It'll just go back to 1970.

When that happens, there already has been added code or validation.
The expected behavior is that on exceeding 2147483647 the value will wrap to -2147483648 which corresponds to Dec 13, 1901 20:45:52 UTC.
Only when there is some "if (time < 0) time = 0;" code it will wrap to 1970.

It will be fixed with a Linux kernel update.

Its already fixed long time ago. You need 64bit CPU and 64bit OS.
The other thing, many network equipment doesn't have RTC clock hardware, simply garbage.

It will be fixed with a Linux kernel update.

Its already fixed long time ago. You need 64bit CPU and 64bit OS.

Not really. From wikipedia article:

Starting with version 5.6 of 2020, 64-bit time_t is supported on 32-bit architectures, too.

ROS v7 (at least 7.9.1) uses linux kernel 5.6.3, so any MT device running ROS v7 (yes, even 32-bit platforms) should be fine. And I guess that devices which don't (realistically) support v7 won't be of much use in year 2038 anyway.

Not it won't. What utter rubbish. It'll just go back to 1970.

Correction: a seqfault can take place based on how the software responds. Seen it happen here in testing.