Sujet : Re: Upcoming time boundary events
De : seaohveh (at) *nospam* hoffmanlabs.invalid (Stephen Hoffman)
Groupes : comp.os.vmsDate : 23. May 2025, 03:31:14
Autres entêtes
Organisation : HoffmanLabs LLC
Message-ID : <100omli$3t023$1@dont-email.me>
References : 1
User-Agent : Unison/2.2
On 2025-05-19 17:18:24 +0000, Simon Clubley said:
I realised that today is exactly 28 years since the 10,000 day issue in VMS. I am starting to feel old. :-(
On a more serious note, I wonder what upcoming time boundaries we are about to hit.
The obvious one is 2038, but I also wonder how many had 2030 as their Y2K pivot point.
Any others you know of (both VMS and non-VMS) ?
Simon.
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
19-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 (details of this one escape me)
31-Dec-2028, HPE root certificate expires, leading to PCSI and VMSINSTAL errors at install
7-Feb-2036 06:28:16 UTC NTP overflow
19-Jan-2038 03:14:07 UTC, signed 32-bit time_t overflow
20-Nov-2038 23:59:37 UTC third GPS rollover.
2057 Local, OpenVMS pivot date (and DEC Centennial)
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
DEC ended the Y2K evaluation range prior to 2038, though at least 2038 bug was identified and resolved within OpenVMS.
VSI has their own signing certificate, and that'll be another bad date to add to this list.
Server consoles have their own limits and oddities around dates.
More:
https://www.theiet.org/media/1631/dates.pdfhttps://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs-- Pure Personal Opinion | HoffmanLabs LLC