• Please review our updated Terms and Rules here

Is this going to be the next Y2K?

Not much of an issue if you just run a 64-bit OS. Current 64-bit versions of Unix, Linux, etc. will have no problems as the "time_t" data type is now 64 bits. I suspect the same for 64-bit Windows, but really can't say for sure.
 
It has already happened. 30 year mortgages required software to be rewritten several years ago. Progressively more software will need to be altered as time advances.

Y2K was mostly a problem of convincing managers to let databases include 4 digit years. Unix will be worse since so much software has been hard-coded to expect 32-bit time.
 
But has it? It would be very surprising if more than a tiny bit of code has been written the last 15 years or more which does _not_ use time_t et co. I know that not one such line has been written since 1990 in my company at least. And we write a lot of code.
 
It is about same time glaciers in Antartic would melt. But you guys care about the 32-bit dates !.
 
Tor said:
But has it? It would be very surprising if more than a tiny bit of code has been written the last 15 years or more which does _not_ use time_t et co. I know that not one such line has been written since 1990 in my company at least. And we write a lot of code.
Click to expand...

The problem arises mostly not from programs themselves, which can be recompiled if source is available, but from old data files which contain raw 32-bit times. There are a variety of ways to deal with these; one is to simply redefine the epoch for files created after a certain date.

The other aspect is determining where the date really matters. I still use Vern Buerg's LIST (version 6.7 plus);this year is displayed as ";4". I know what it means.
 
Stone said:
What? Not even any academic curiosity? :)
Click to expand...

My academic curiosity extends to matters of "will anyone still be around in 2038?" Really, Y2K wasn't much of a blip in the history of human civilization, in spite of predictions of planes falling out of the sky and the arrival of the Apocalypse.
 
Ah, LIST.. I loved that program. But I haven't used it since my DOS days, a very long time ago. I remember implementing a (simpler) lookalike for the minicomputer that was my main platform.
 
IIRC there was also a concern I thought on mainframes or some other OS that it thought if a file had the date 11/11/11 it should delete it that night as it's a test/temporary file. anyone remember that one or the correct date?

On a side note I still remember our manager had to sleep in the data center on 12/31/1999 per orders from the director and higher ups. "Just in case".
 
All that needs to happen is for everybody to update all their applications to use the appropriate standard. Which, since this is Unix (and, more importantly, Linux) we're talking about, should happen right around the time VMS systems encounter the Year 31,086 Problem they've been counting on not dealing with since its inception in 1977.
 
commodorejohn said:
... around the time VMS systems encounter the Year 31,086 Problem they've been counting on not dealing with since its inception in 1977.
Click to expand...

Why hasn't anybody else used the epoch date of November 17, 1858? And is keeping time in 100ns intervals enough resolution for today's systems? I guess this interval does have the advantage that it corresponds to a 10MHz frequency (common external clock frequency for counters, GPSDO, etc).

Dave Cutler kept the interval (100ns) he used in VMS when he wrote NT, but dropped the epoch for January 1, 1601. WTF? The linked discussion indicates there may be a Y4K problem in Windows... but I doubt it.

How big a value would we need to count Cs-133 transitions since the big bang? Let's see, that's 9,192,631,770 * 31,557,600 * 13,610,000,000 (or so) which is about a 92 bit number this week... I guess 128 bits should take care of it for now (did I slip up somewhere?).
 
Last edited:
You must log in or register to reply here.
Back
Top