On 2022-05-19 18:02:36 +0000, Simon Clubley said:
> I wonder when the first Y2038 failures will start occurring ?
They've already been occurring.
> One of our internal webservers at the office blew up. It's an intricate
> and bizarre hack on a little-used platform, and we're terrified of it
> dying because our knowledge of the internals is bad. I was pretty sad
> about it, and especially so because I had to fix it.
>
> A careful search of the internet found a mailing list thread in which
> many, many other people had the same problem, all starting after
> 2006-05-12.
>
> The thread starts here:
>
http://www.mail-archive.com/aols...@listserv.aol.com/msg09812.html
>
> What turned out to be the problem? All these systems failed at the same
> time, exactly one billion seconds before the 32-bit Unix epoch ends in
> 2038. The timeouts set for database threads caused the software to look
> ahead, gasp in horror and died.
>
> Ladies and gentlemen I'm in a select club of the first victims of the
> Year 2038 Bug.
>
> My job is weird.
Closer to the comp.os.vms newsgroup, DEC found and fixed at least one
time_t overflow bug in OpenVMS, that though 2038 was outside the Y2K
review.
I expect we're headed for another Y2K-style review and certification
process, too.
Probably-partial list of bad dates for OpenVMS:
17-Nov-1858 00:00 UTC, OpenVMS base date
1-Jan-1970 00:00:00.00 UTC, epoch
17-May-1997, the LIBRTL 10K Day limit that derailed DECwindows
1-Jan-2000 Local, Y2K, various bugs and limits found and fixed in OpenVMS
2003 Local
31-Dec-2028, HPE root certificate expires.
19-Jan-2038 03:14:07 UTC, signed 32-bit time_t overflow
2057 Local, OpenVMS pivot date
7-Feb-2106 06:28:15 UTC unsigned 32-bit time_t overflow
1-Jan-10000 00:00:00.00 Local, four digit year overflows
31-Jul-31086 02:48:05.47 UTC, end of the OpenVMS epoch
--
Pure Personal Opinion | HoffmanLabs LLC