"Olson, Arthur David (NIH/NCI)" <olsona@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.