Realised on the way to work this morning that it is now a quarter of
a century since Y2K. 25 years! :-(

Anyone else depressed by that thought ?

BTW, it's now a little over 13 years to the end of the world...

Simon.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/8/2025 11:21 AM, Johnny Billquist wrote:

On 2025-01-02 14:44, Simon Clubley wrote:

BTW, it's now a little over 13 years to the end of the world...

For some Unix systems, yes. Not sure if that is relevant in a newsgroup
for VMS...

Old *nix using signed 32 bit seconds since 1970 will have a problem.

The seconds since 1970 concept has also sneaked into many VMS
applications via C, but time_t in VMS C is unsigned 32 bit,
so we will first have the problem in 2106!

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-01-02 14:44, Simon Clubley wrote:

Realised on the way to work this morning that it is now a quarter of
a century since Y2K. 25 years! :-(

Indeed. And yes, time floes.

Anyone else depressed by that thought ?

Not depressed maybe, but it do cause some reflections.

BTW, it's now a little over 13 years to the end of the world...

For some Unix systems, yes. Not sure if that is relevant in a newsgroup
for VMS...

Johnny

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-01-08 16:21:20 +0000, Johnny Billquist said:

On 2025-01-02 14:44, Simon Clubley wrote:

BTW, it's now a little over 13 years to the end of the world...

For some Unix systems, yes. Not sure if that is relevant in a newsgroup
for VMS...

I'm aware of 2038 bugs that were found and fixed within OpenVMS some
years back, and there may well be others awaiting.

The OpenVMS Y2K evalation expressly excluded testing of 2038 and later
dates, as well. Terra (or tempora) incognita.

If you're running production on OpenVMS for the next decade or so, boot
up a test guest, and test your code and test your environment past 2038.


--
Pure Personal Opinion | HoffmanLabs LLC

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-01-09 20:35, Stephen Hoffman wrote:

On 2025-01-08 16:21:20 +0000, Johnny Billquist said:

On 2025-01-02 14:44, Simon Clubley wrote:

BTW, it's now a little over 13 years to the end of the world...

For some Unix systems, yes. Not sure if that is relevant in a
newsgroup for VMS...

I'm aware of 2038 bugs that were found and fixed within OpenVMS some
years back, and there may well be others awaiting.

The OpenVMS Y2K evalation expressly excluded testing of 2038 and later
dates, as well.  Terra (or tempora) incognita.

If you're running production on OpenVMS for the next decade or so, boot
up a test guest, and test your code and test your environment past 2038.

I can definitely see that for C code using C functions. Also, wasn't
there some issue with C code in some runtime environment under VMS where
times were expressed as delta times which hit a problem at 10000 days?

But apart from things centered around C one way or another, I can't see
that VMS would care.

Johnny

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/9/2025 9:00 PM, Johnny Billquist wrote:

On 2025-01-09 20:35, Stephen Hoffman wrote:

On 2025-01-08 16:21:20 +0000, Johnny Billquist said:

On 2025-01-02 14:44, Simon Clubley wrote:

BTW, it's now a little over 13 years to the end of the world...

For some Unix systems, yes. Not sure if that is relevant in a
newsgroup for VMS...

I'm aware of 2038 bugs that were found and fixed within OpenVMS some
years back, and there may well be others awaiting.

The OpenVMS Y2K evalation expressly excluded testing of 2038 and later
dates, as well.  Terra (or tempora) incognita.

If you're running production on OpenVMS for the next decade or so,
boot up a test guest, and test your code and test your environment
past 2038.

I can definitely see that for C code using C functions. Also, wasn't
there some issue with C code in some runtime environment under VMS where times were expressed as delta times which hit a problem at 10000 days?

But apart from things centered around C one way or another, I can't see
that VMS would care.

Stuff using real VMS time will obviously not have a problem.

But there are a lot of C code also on VMS. Newer applications
written within the last 25 years. Applications and platform
software ported from *nix.

I would expect it to be a 2106 problem though not a 2038
problem due to time_t being unsigned on VMS.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/01/2025 02:00, Johnny Billquist wrote:

I can definitely see that for C code using C functions. Also, wasn't
there some issue with C code in some runtime environment under VMS where times were expressed as delta times which hit a problem at 10000 days?

But apart from things centered around C one way or another, I can't see
that VMS would care.

  Johnny

DEC Basic by default had dates stored in a signed work as year since
1970, plus Julian day. Hence the would have broken at the start of 2003

--
Chris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-01-10 02:00:17 +0000, Johnny Billquist said:

On 2025-01-09 20:35, Stephen Hoffman wrote:

On 2025-01-08 16:21:20 +0000, Johnny Billquist said:

On 2025-01-02 14:44, Simon Clubley wrote:

BTW, it's now a little over 13 years to the end of the world...

For some Unix systems, yes. Not sure if that is relevant in a newsgroup
for VMS...

I'm aware of 2038 bugs that were found and fixed within OpenVMS some
years back, and there may well be others awaiting.

The OpenVMS Y2K evalation expressly excluded testing of 2038 and later
dates, as well.  Terra (or tempora) incognita.

If you're running production on OpenVMS for the next decade or so, boot
up a test guest, and test your code and test your environment past 2038.

I can definitely see that for C code using C functions. Also, wasn't
there some issue with C code in some runtime environment under VMS
where times were expressed as delta times which hit a problem at 10000
days?

But apart from things centered around C one way or another, I can't see
that VMS would care.

Somewhere between a third and a half of the OpenVMS operating system is
written in C.

While it would be nice to make assumptions about the ubiquity of
quadword and octaword time format usage, there already have been issues identified and resolved in OpenVMS itself.

I would not exclude additional 2038 issues in OpenVMS components, and
in application and third-party components, from arising.

Test.


--
Pure Personal Opinion | HoffmanLabs LLC

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)