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