I thought today's date was familiar and then I realised it's
exactly 25 years ago today since the 10,000 day delta time issue.

I am now depressed that I am now old enough to have events in my
professional life from 25 years ago... :-( or :-) (not sure :-))

On a more serious note, it's about 15 years to Y2038, which no
longer seems so far away.

I wonder when the first Y2038 failures will start occurring ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

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/aolserver@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

On 5/19/2022 3:26 PM, Stephen Hoffman wrote:
> 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

The last two does not worry me so much.

:-)

Arne

On 2022-05-19, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>
> 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

19-May-1997.

> 1-Jan-2000 Local, Y2K, various bugs and limits found and fixed in OpenVMS
> 2003 Local
> 31-Dec-2028, HPE root certificate expires.

Do you know what the practical effects of that one will be for VMS sites ?

> 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

There was also an old SPR or problem report where something would fail
around the year 5xxx (IIRC). The answer said the problem would be fixed
sometime before that date.

I've totally forgotten the details however...

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

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-05-20 13:03:27 +0000, Simon Clubley said:

> Do you know what the practical effects of that one will be for VMS sites ?

All DEC/Compaq/HP/HPE-signed layered product software installation
checks will fail to verify the kit signatures, and the checks must be
overridden to permit installations.

VSI is using their own signature AFAIK, which would mean there's a VSI
"bad date" to be added to the list. I've not checked the VSI
certificate and its expiration.

Pragmatically, it'll mean folks arriving here not having searched for
previous discussions, all reporting failed PRODUCT INSTALL and failed
VMSINSTAL layered kit install sequences.

--
Pure Personal Opinion | HoffmanLabs LLC