Author Topic: Are your devices Y2038K compliant?  (Read 207 times)
Lightingguy1994
Administrator
Member
*****
Offline

View Posts
View Gallery


Are your devices Y2038K compliant? « on: September 27, 2021, 01:42:35 AM » Author: Lightingguy1994
Any device that uses a signed 32 bit integer to store its time will default to 20:45:52  Friday, 13 December 1901 once it hits 03:14:07 Tuesday, 19 January 2038 (see attached gif).

Many older devices and even new ones will suffer this. Whats your plan for when this happens? Especially you vintage computer collecters / users?


Logged

Administrator #5

Medved
Member
*****
Offline

Gender: Male
View Posts
View Gallery

Re: Are your devices Y2038K compliant? « Reply #1 on: September 27, 2021, 03:34:06 AM » Author: Medved
Just to tease a bit: Well, the title makes it a bit irrelevant for some time: Year 2038000 is still long way to go... :-)

But to more of a serious note: There are way more "YXXXX" bugs around. For many devices, mainly computers, the 1 second is rather coarse unit, so there won't be much systems
having this exact issue.
Quite "popular" are "ms" (uint32 expires a bit after 3 years; but that is so often those use to be designed for that overflow to happen normally, so no big deal then), many use multiple registers but each of them shorter (these were in fact the ones the "Y2K" was really threatening). By the way the same category would be the Y2027 (year stored in a 7bit format, e.g. when MSB used for some extra function like media wear leveling,...) and so on.
Those many formats are so diverse (usually tailored for specific use), you can not track all of them... Don't forget the bit width in use is not just the typical bit lengths of 8, 16, 32, 64,..., but as well the 20, 24, 36, 40, 48, but even 15, 19, 23, 31,... (any from above minus 1 bit used for storage media wear leveling flag) when e.g. EEPROM storage is limited or even multiples of some crazy number (usually number of bits in the EEPROM space left programmed each 100m the car drives, only when full this section is erased and the register incremented).
Those two obvious (Y2K, Y2027 and the Y2038) may even not be the most frequent in use.

But it is true, such format is tempting to use for an intermediate processing before displaying. But when used for anything else (like calculate time since last stored event) it should yield correct result even when it overflowed in the meantime (assume the time events are closer to each other then half of the overflow cycle)...

In fact if the thing was audited and patched in the "Y2K" furry, whatever the true limit, it has been most likely fixed (then the time formats were checked and patches designed and deployed for all such issues).
Logged

No more selfballasted c***

Rommie
Administrator
Member
*****
Offline

Gender: Female
View Posts
View Gallery

Andromeda Ascendant


Re: Are your devices Y2038K compliant? « Reply #2 on: September 27, 2021, 07:47:10 PM » Author: Rommie
I have enough problems wondering how I'm going to get as far as the end of the day, I don't have time to worry about what may or may not happen in 17 days/months/years  :mrg:

I just hope  :curse: face masks are gone before then  :'(
Logged

Ria (aka Rommie) in Aberdeen
It'll be all right in the end, and if it isn't all right, it isn't the end :love:

Administrator, UK and European time zones. Any questions or problems, please feel free to get in touch
:love:

Print 
© 2005-2021 Lighting-Gallery.net | SMF 2.0.18 | SMF © 2021, Simple Machines