| 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).
|
