64-bit time_t must go--this is non-negotiable

Paul Eggert eggert at CS.UCLA.EDU
Thu Jun 17 19:56:47 UTC 2004

"Olson, Arthur David (NIH/NCI)" <olsona at dc37a.nci.nih.gov> writes:

> time_t has been a 32-bit entity since day one of UNIX,

No, actually, it was a 'long' entity.  The very first UNIX ran on the
PDP-7, which was an 18-bit host, so I suspect (though I can't easily
check this :-) that time_t was a 36-bit quantity on the very first
UNIX host.  Certainly the circa-1978 Honeywell 6000 UNIX port used a
36-bit time_t, so there's longstanding precedent that time_t is not
always exactly 32 bits.

> The historic precedent in the UNIX realm is the addition of the
> "lseek" system call once files got larger

That predated C's typedef feature.  A closer precedent is what
happened to lseek when file offsets grew from 32 to 64 bits.  By this
time, people were supposed to use "off_t", and "off_t" grew from 32 to
64 bits without changing the name of "lseek".  (The story is a bit
more complicated than this, but that's the general idea.)  The changes
to time/ctime/etc. are similar.

> we should probably not be doing a lot of work to support 64-bit
> time_t implementations since we don't want to encourage such
> implementations.

I'm afraid the ship has already sailed on this issue, and it's too
late to reverse course, even assuming everyone agreed on the general
principle.  The vast majority of 64-bit hosts use 64-bit time_t.  This
includes GNU/Linux, the BSDs, HP-UX, Microsoft Windows, Solaris, and
probably others.  There are one or two holdouts (Tru64 comes to mind)
but they're a clear minority.

I wouldn't ask you to do a lot of work in this area, since you have
other things to do.  But if someone else volunteers to fix the porting
problems it seems like a fairly easy call.

zdump is intended to be used with other time_t implementations and so
it's more important that it support non-32-bit time_t.  (zic is also
important, but I don't know of any problems that it has with
non-32-bit time_t.)  The other code is less-important, since the
non-32-bit-time_t guys have mostly rewritten all that stuff anyway;
but the fixes there are relatively small.

More information about the tz mailing list