2038: only 21 years away

Posted Mar 16, 2017 8:23 UTC (Thu) by mjthayer (guest, #39183)
Parent article: 2038: only 21 years away

Would it make any sense, for the places where 32-bit time stamps can not be fixed, to slide the time window they represent? I am sure that by 2038 there will not be that many cpio archives from 1970 in common use, and perhaps people can just live with the fact that the few that are will have wrong timestamps?

2038: only 21 years away

Posted Mar 16, 2017 12:07 UTC (Thu) by epa (subscriber, #39769) [Link] (2 responses)

The new Epoch could be 2011-10-12?

2038: only 21 years away

Posted Mar 16, 2017 13:11 UTC (Thu) by lkundrak (subscriber, #43452) [Link] (1 responses)

Why that particular date?

2038: only 21 years away

Posted Mar 18, 2017 2:32 UTC (Sat) by CChittleborough (subscriber, #60775) [Link]

I guess it's because that's the date of Dennis Ritchie death.

2038: only 21 years away

Posted Mar 16, 2017 12:43 UTC (Thu) by sorokin (guest, #88478) [Link] (5 responses)

The problem I see is that time stamps are not only printed, but also compared. And usually they are compared using built-in comparison operators of C.

If they were opaque structs with overloaded C++ operators <, >, = that would be more feasible. But if they were opaque structs we would have no problem in the first place.

2038: only 21 years away

Posted Mar 16, 2017 13:46 UTC (Thu) by mjthayer (guest, #39183) [Link] (4 responses)

> The problem I see is that time stamps are not only printed, but also compared.

Ahem, yes. And time_t is signed, which means that it cannot just be let to overflow and continue, which was what I had in mind.

2038: only 21 years away

Posted Mar 16, 2017 15:00 UTC (Thu) by dd9jn (✭ supporter ✭, #4459) [Link] (3 responses)

time_t is not signed. C99 merely says:

clock_t and time_t
which are arithmetic types capable of representing times;

thus it is undefined whether it is signed or unsigned. Traditionally the return value of time() was a long and thus many implementations used to typedef time_t as long. But there is no need for this and it would work just fine with an unsigned integer, if there would not be code which uses

if (time(NULL) < 0) oops();

or uses (before - after) terms. Portable programs won't have a problem with an unsigned time_t. But nevertheless making time_t unsigned is an ABI change and thus it is easier to do it like BSD and directly switch to a 64 bit type.

FWIW, around 2003 I met with the glibc maintainer to ask him to start migration to a 64 bit time_t. Back then I was in a need for post 2038 timestamps due to some root certificates having an insane long term. Uli rejected that with the claim that time_t was never intended to represent arbitrary times (i.e. future timestamps) :-(

2038: only 21 years away

Posted Mar 16, 2017 15:06 UTC (Thu) by ianmcc (subscriber, #88379) [Link]

*bangs head against wall*

2038: only 21 years away

Posted Mar 17, 2017 1:35 UTC (Fri) by gdt (subscriber, #6284) [Link] (1 responses)

undefined whether it is signed or unsigned

C is even more undefined than you suggest. An implementation must use an "arithmetic type", but need not supply an arithmetic value within that type. The ANSI C Rationale says

No arithmetic properties of these types are defined by the Standard … The representation need not be a count of some basic unit; an implementation might conceivably represent different components of a temporal value as subfields of an integer type.

So you can see that ANSI C gives a programmer wanting to write portable time_t handling code very little. Only the ability to compare a time against (time_t)(-1) to check for errors. You could argue that ANSI C allows a time_t to be compared for equality, but you friend could counter-argue that the Standard doesn't forbid multiple representations for the same time in a time_t. ANSI C does require that a time in a struct tm returned by a library has only one representation. The ANSI C committee created difftime() to give the language more time_t handling ability; however that returns a double, which is problematic for some programming tasks.

Thankfully POSIX/SUS applies additional requirements for time_t on UNIX-like systems. "The time() function shall return the value of time in seconds since the Epoch".

As far as I can tell, POSIX/SUS makes no statement on the signedness or unsignedness of time_t, thus neither can be relied upon by a programmer.

Implementation practice in AT&T and BSD UNIXen prior to POSIX was that time() was signed. Of course, such practice shouldn't be relied upon by a programmer.

2038: only 21 years away

Posted Mar 23, 2017 15:09 UTC (Thu) by Wol (subscriber, #4433) [Link]

So if a user space programmer wants to use time_t to represent dates at the start of last century ... ?

Okay, I'm used to a database that represents dates as "days since epoch" (1 Jan 1967 iirc), but negative dates are a matter of course ... :-)

Cheers,
Wol