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

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

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.