When Unix Clocks Hit 10-Digits Will Anything Break?

dannycarroll asks: "I've not heard this mentioned yet so I'll bite. This weekend (depend on where you live) the Unix system clock hits 1.000.000.000 seconds since the Unix Epoch. I heard about one or two applications that are vulnerable to a date overflow but I am wondering how many more are out there, unknown. It's not the Y2k bug and consequences are far from it, but it seems to me that there has been too little attention paid to this potential problem. As an example, I wonder how many Perl scripts out there use 9 digits for the date-stamp field instead of a delimiter?" I've been hearing about this from several different directions and it took me by surprise. I would think that most programs out there are using time_t or at least 32-bit integers by now if they are storing seconds-since-the-epoch (you would think we actually had learned something from the Y2K chaos). Are there any well known programs that might break because of this?

Comments

I for one am hoping things will be affected.

[Dashslot]

Lets be honest, I hope there are problems as it'll make things more interesting around here. But, I think there isn't much chance of that, as anyone clever enough to be using time_t to store stuff, isn't then going to whack it into a 9 character long string..... One hopes.

Validation stuff, and lots more

[Matts]

There's a lot of validation done on date strings (i.e. check it's 9 digits). For example, there's a lot of code out there that creates filenames based on this 9 digit string, and then there's apps that load up those files. There's also cookies that get set based on the epoch seconds. Any sanity checking that looks for a 9 digit integer is going to go bang. I've come across some of that code where I work. I'm sure other people will too, and it's all too easy to ignore due to the lack of hype surrounding the 1e9s bug.

KMail breaks

[red_dragon]

This article on KDE Dot News describes the the 1,000,000,000th second bug in KMail < 1.0.29.1. The problem stems from the index file format used (the time stamp is a 9-char fixed-width field). The index files (and therefore the mail folders) become corrupted when the time value is >= 10^9. This doesn't have anything to do with time_t, which on 32-bit systems is slated to roll over sometime in 2038. Systems with 64-bit timestamps (like pre-X Mac OS and VMS) won't roll over for the next 20,000 years.

Re:KMail breaks

[jhines]

VMS had an issue, just before the 2000 event, when one of the temporary storage variables in a library time routine overflowed.

There are many things that a programmer can do that will cause problems, that is why testing has to be done under extreme circumstances, using the full range of values.

Re:KMail breaks

[Anonymous Coward]

Systems with 64-bit timestamps (like pre-X Mac OS and VMS) won't roll over for the next 20,000 years

While factually true, that statement is misleading. Systems with 64-bit timestamps won't roll over for more than two hundred billion years (assuming the timestamp is in seconds as most (all?) time_t implementations are, but even in microsoeconds it's 200,000 years).

Re:KMail breaks

[randombit]

Systems with 64-bit timestamps (like pre-X Mac OS and VMS) won't roll over for the next 20,000 years.


Also, most 64-bit Unix systems are using 64-bit time_t's, since on most systems I've seen, it's a long (I just checked it on Solaris and Linux, but I imagine this is true basically everwhere). So, as long as you're using a 64-bit machine, you're probably safe.

Since by 2038 (rollover time), 32-bit machines will be mostly unused (I imagine that by that time they will only exist as obsolete hardware and embedded stuff), the 32-bit timestamp problem doesn't really exist, at least on the normal programmatic level.

However, many standards (for example OpenPGP), use timestamps which are explicitely 32 bits long. This will cause some problems, but should be fairly simple for implementations to work around (after all, a PGP signature was probably not made in 1970, so you could probably say that if the timestamp comes before some reasonable date, like say 1990 or 1995, just add the appropriate amount of time).

So, for those of you creating formats, remember that 64-bit timestamps are your friend.

Re:KMail breaks

[Genoaschild]

2^64=18446744073709551616

Assume 1 ns per tick. Their are 1000000000(1*10^-9) ticks in one second. Their are 60 seconds/minute, 60 minutes per hour, 24 hours per day, and ~365.24 days per year. Multiply those together you get 31556736000000000 ticks for every year. 2^64/ans = 584 years. 584,000 years for microseconds. The point is, if you assume an unsigned time stamp and microsecond/tick, it is more like five hundred thousand years and not 200 thousand years. Big difference. It really doesn't matter because we are not going to live that long to see it roll over but it is still interesting.

Hopefully people will have thought this out.

[Maul]

I'm working on a piece of software now that uses the time string quite a bit. When I was first designing it, I first was going to make the software expect a nine digit string, because as long as I remember it has been that. But then I noticed how the time strings were getting pretty close to ten digits. If I would have been careless, I'd be dealing with broken software this weekend.

Of course, since there are lots of more competant programming geeks than me, I'm sure that most of the good software out there will be okay. (Or at least I hope so)

Re:Hopefully people will have thought this out.

[jmauro]

So you made the stirng 10 digits then? You're really just pushing the solution off to someone else to solve later. That was bad programming I think. Use time_t and covert to a string as needed. Anything else is silly.

Re:Hopefully people will have thought this out.

[JohnKFisher]

So you made the stirng 10 digits then? You're really just pushing the solution off to someone else to solve later.

Um, correct me if I'm wrong, as it would take me valuable seconds to do the actual math, but isn't that, what, 300 years away before we go to 11 digits? I would hope his program would not still be in use.

Re:Hopefully people will have thought this out.

[jmauro]

He's just stalling before the invitable occurs.

I would guess sorting might break...

[Ami Ganguli]

I doubt there's a lot of software that explicitely depends on the date being nine digits. It's not like the Y2K bug, where the most convenient form to manipulate the date was often as a string. People using the Unix time for their date would normally find it easier to manipulate the value as an integer. As long as they stick to that they're fine.

Where there might be problems (and I'm guilty of doing this) is where the developer took advantage of the fact that dates sorted alphabetically also happen to be sorted temperally. Say you save dated information in files and incorperate the timestamp in the file name. When you read the file name back in it's a string. If you need the most recent data, it's tempting to sort it as a string and pick off the last item (especially if you're using Perl which makes this sort of manipulation really easy). Unfortunately string comparisons will stop working on Saturday ("1000000000" 999999999).

It's time for 64-bit time ...!

[mikewhittaker]

Now we saw all the heat generated by Y2k, it's time to start using a time representation that's got a bit more mileage in it than the current 32 bits - like 64 bits.

Unix time overflow (signed or unsigned) may be some years away, but why wait, especially now that an ever-increasing amount of goods contains processing power.

Using 64-bit time, with the 2^63 pivot point (0x80...00) set at the current epoch of 1/1/1970, would allow a 64-bit time id for each second in human history: plus or minus 2.9 exp 11 years (if my arithmetic is correct).

Or perhaps the gurus think that our current concepts of timekeeping will become obsolete in the next 30 years: maybe a second is too granular ....

(I am aware that VMS used 64-bit time, but that was nanoseconds, IIRC, and would run out far too soon!)

Re:It's time for 64-bit time ...!

[jon doh!]

not granular, but we'll eventually go to metric time ;P

Re:It's time for 64-bit time ...!

[jhines]

VMS used clunks which were 100 nS units. IE one clunk was a tenth of a MS. And it was the time since the epoch of Nov 18 1858 (?) which is a standard time base.

VMS actually had a bug report filed on it, that the time would overflow the standard format after the year 10K, but a fix was promised by then.

Whoops...

[Ami Ganguli]

I forget to escape my "<" at the end there. That should say: ("1000000000" < "999999999", although 1000000000 > 999999999).

Lots of clumsy programmers

[polymath69]

Novice programmers do all sorts of nutty things. I've caught in code review people using char[10] to hold timestamps as recently as a year ago, blithely unaware that this would soon overflow. In that particular case, it was even more ironic as it would have been more efficient to simply pass the 4-byte int between the processes in question. The decimal conversion was completely unnecessary.

That same code review turned up another ignorance-borne gem.

void intToChar(int pTime, char spTime[])
{
int i, sign;
if ((sign = pTime) < 0)
pTime = -pTime;
i = 0;
do
{
spTime[i++] = pTime % 10 + '0';
} while ((pTime /= 10) > 0;
if (sign <0)
spTime[i++] = '-';
spTime[i] = '\0';
reverse(spTime);
}

void reverse(char spTime[])
{
int c,i,j;
for (i=0,j=strlen(spTime)-1; i<j; i++,j--)
{
c = spTime[i];
spTime[i] = spTime[j];
spTime[j] = c;
}
}

If you look at this, it's actually almost ingenious. But no seasoned programmer would write this, since it all boils down to sprintf (spTime, "%d", pTime);. There's no substitute for experience.

Which brings me back to my point. How much code must there be out there that was written by low-level programmers who are assigned the simpler and more tedious sections of the code? Usually the architects and designers concentrate on the "big picture" and most difficult sections of code, but invariably there are parts left for the junior developers, who by definition are still on the road to programming common sense.

So we are bound to see this manifest. Most likely, like y2k, nothing critical will fall over and blow up. But also like y2k, we'll be finding the cosmetic (and more occasionally, serious) consequences of this bug in all sorts of places, and for quite some time.

Re:Lots of clumsy programmers

[3247]

"...since it all boils down to sprintf (spTime, "%d", pTime);"

Well, you forgot the interesting part:

char pTime[10];
sprintf (spTime, "%d", pTime);"

Re:Lots of clumsy programmers

[polymath69]

Naw, I didn't forget it. On the contrary, I said that this was the other main problem found at that code review, as indeed the routine intToChar() was being called with a char[10] argument!

It would surely have blown up by now... except that we caught it... and then that the project was eventually cancelled, partially because these consultants kept making the same sorts of errors and we just weren't getting anywhere. Sigh.

Explanation via google

[hodeleri]

http://www.inwap.com/pdp10/usenet/julian-day

Remember To Fix 64-bit Time

[SEWilco]

Make sure you create a cron entry which will email you a reminder when the 64-bit limit is approaching so you can fix your code.

People with bad clocks are already testing this

[hamjudo]

Some percentage of system clocks are just set wrong. I sorted my email by date, the message with the worst time warp was dated Sun, 24 Jan 2094 14:55:27 +0100.

These people with flaky hardware and/or flaky administrators are providing a valuable service and testing bunches of applications for us. This does provide uneven coverage, applications for the clueless get the most wrong date testing. The headers say that message from 2094 was sent with Microsoft Outlook Express 5.50.4133.2400.

Re:People with bad clocks are already testing this

[orangesquid]

I had a laptop that worked fine up until 1997, at which point it suddenly decided it was 2097. It used an OLD PhoenixBIOS I _think_. My only guess is that the BIOS clock-setting utility was designed to have Y2K support but used a century flag that happened to sit over some bit position they didn't foresee being in use :D

Sun Microsystems Technical Bulletin

[AtariDatacenter]

Sun has released a technical bulletin on this. It doesn't appear to be NDA or confidental, but then again, they don't always label their stuff. (I had a problem with that once. Not even a copyright notice. They screamed and yelled when the document hit the net.)

They do, however, reference the following URL at the end of the bulletin --

http://www.mitre.org/research/y2k/docs/TIME_T.html

There is no geographic dependency

[Anonymous Coward]

All UNIX systems store the UTC+0 time, so they will
all overflow at the same time.
( of course in reality many systems are misconfigured,
so they will overflow "sooner-or-later" )

stein