[OT] Time flies...

[Simon Clubley]

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.

[Johnny Billquist]

Post by Simon Clubley
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.

Post by Simon Clubley
Anyone else depressed by that thought ?

Not depressed maybe, but it do cause some reflections.

Post by Simon Clubley
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

[Arne Vajhøj]

Post by Johnny Billquist

Post by Simon Clubley
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

[Stephen Hoffman]

Post by Johnny Billquist

Post by Simon Clubley
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.

[Johnny Billquist]

Post by Stephen Hoffman

Post by Johnny Billquist

Post by Simon Clubley
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

[Arne Vajhøj]

Post by Johnny Billquist

Post by Stephen Hoffman

Post by Johnny Billquist

Post by Simon Clubley
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

[Chris Townley]

Post by Johnny Billquist
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