Is there any fix for WinME's system restore y2038 bug?

[xkai]

WinMe's system restore has a bug that the restore operation will fail if you choose a restore point created after 2001/9/9 1:46:39 utc, because the interval of this time point and the beginning of the 32-bit unix time_t time point (1970/1/1 0:00:00 utc) is 999999999 seconds, which is the maximum 9-digit number. If the seconds of this time interval get to a 10-digit number, the bug occurs. The bug is in the smgr.dll file. To fix this bug, M$ released a critical update q290700. It updates this file to the version 4.90.0.3003. But the updated smgr.dll still has a y2038 bug. If there is a restore point created after the end of the time point of the unix 32-bit time_t (2038/1/19 3:14:07 utc - which is the beginning time point of the y2038 bug), the system restore program even can't start - causes an illegal operation!  

[jaclaz]

So, if I get this right, for the next 14 years, ME users are fine?

jaclaz

[Tripredacus]

IIRC the is 2038 issue effects all systems that use the 4-byte integer for time with a start date of 1/1/1970, including the previously mentioned Unix. I do not know of a full list of OSes (and hardware) that have this issue but I doubt WinME will be any sort of priority. Presumably it could also effect any system with a clock that has a year, like maybe a VCR. So now consider what types of non-computers that exist in the commercial or industrial space that could potentially have this problem.