Date: Thu, 17 Jun 2004 12:56:47 -0700 From: Paul Eggert <eggert@CS.UCLA.EDU> Message-ID: <87d63yj6v4.fsf@penguin.cs.ucla.edu> | "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. No, it wasn't. | 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. It probably was, but it wasn't long. Back in those days there was no C to have the modern concept of "long" at all, and even when C existed initially, there was no "typedef" to create new types (like time_t). That's all relatively recent additions (well, 7th edition, 1979 or so). In the earliest unix, time() operated on a int [2] array (which is why time() and all the other time related funcs, has their time args passed as a pointer - having time() return the value as well is another recent addition). The first unix on 32 bit processors actually had times represented as 64 bits, as that kept on using int[2] except with 32 bit ints (this was the University of Wollongong (Richard Miller) port of v6 unix to the Interdata (Perkin Elmer later) systems (which preceded the Bell Labs Interdata port which much influenced v7). When that switched to v7 it went back to 32 bits (using "long"). | > 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. yes, though ado still has a point, one still does need to handle existing applications that know time_t as a 32 but quantity. While the name of lseek wasn't changed (as known by the C compiler) to move from 32 to 64 bit offsets, the actual system call certainly was changed (the 32 bit version still exists on any architecture old enough to have had applications from when lseek took 32 bit offsets). Other changes of a similar nature have actually had source visible modifications - which is the better approach for any particular change requires careful thought and study. Certainly it isn't correct to simply cite the precedent of some other (different) change, and act as if that was sufficient justification for any new change. Personally, at the minute, I have no idea whether making time_t a 64 bit type, or introducing a new type for bigger times is the better approach. If FreeBSD are trying it in some limited sense, that's great, and will provide feedback on how well things work (though doing FreeeBSD sparc64 probably isn't a great test for existing applications...) I'm also by no means convinced that a 64 bit time_t that is just twice as many bits, bit otherwise unchanged from, our current 32 bit time_t is a rational thing to do. I can't imagine wanting to know about times that stretch from 1970 to 1970 + 2.6 * 10^11, that's just absurd. When more bits are added, the time base should probably be moved (a long way), and lots of the extra bits (say 20 or the added 32) should be used for extra precision, rather than extra years. Put the 0 value at about 10000 years info the future (say year 10000 itself), allow + and - time values, and 44 bits of year values stretches from before year -270K to almost year 300K, which is plenty of range, with microsecond precision. But this is just one possibility - not necessarily a good one, but certainly better than 2^64 bits of seconds. kre