std-unix@ut-sally.UUCP (Moderator, John Quarterman) (08/29/86)
From: elsie!ado@seismo.UUCP Date: Mon, 25 Aug 86 18:35:05 EDT Subject: negative time_t values While it's true that no UNIX files date back to before January 1, 1970, there *are* uses for times before that epoch: in personnel data bases where birth dates are recorded; in data bases recording astronomical events; in stock market price data bases (as used by chartist fanatics); and elsewhere. (And what of all those old 7094 executables that are being used on IBM machines running UNIX or a cousin? :-)) I see more use in the short run for being able to record times between 1901 and 1970 that I see for being able to record times after 2038. And if we do make it into the twenty-first century, I imagine we'll be working on machines with 256-bit registers where time_t will have a type that allows it to represent times into the very distant future; if it's defined properly, time_t variables will also be able to represent times into the very distant past. In summary: I'd recommend retaining the ability for time_t variables to represent times before 1970. -- UNIX is an AT&T registered trademark. Time is a Time/Life Incorporated trademark. IBM is an IBM trademark. -- UUCP: ..decvax!seismo!elsie!ado ARPA: elsie!ado@seismo.ARPA DEC, VAX, Elsie & Ado are Digital, Borden & Ampex trademarks. Volume-Number: Volume 6, Number 41
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (09/04/86)
From: sun!gorodish!guy@utastro.UUCP (Guy Harris) Date: Sat, 30 Aug 86 20:39:06 PDT > While it's true that no UNIX files date back to before January 1, 1970, > there *are* uses for times before that epoch: Yes, but there are other representations for such dates and times; there's no particular need to have "time_t" objects represent dates in 4004 BCE, for example. Most of the time, they are represented as mixed-radix numbers, giving year, month, day, etc., or year, day of year, etc.. The standard arithmetic functions on dates (date1 - date2, date1 + offset, etc.) are possible, if slightly less convenient, as are comparisons of dates. Most of the examples given don't currently use "time_t", as they're not done on UNIX systems, and there's no good reason to change them and not much reason to use "time_t" for future programs of those sorts. ("time_t" is an especially poor choice for astronomical event databases; many interesting such events occurred more than 68 years before 1970....) > I see more use in the short run for being able to record times between > 1901 and 1970 that I see for being able to record times after 2038. Yes, but is there a use for recording UNIX file modification times between 1901 and 1970? Other times can be recorded in forms other than a "time_t". > In summary: I'd recommend retaining the ability for time_t variables to > represent times before 1970. It's not a case of "retaining". The 1003.1 Trial-Use Standard says that the result of "time" represents "the value of times in seconds *since* 00:00:00 GMT, January 1, 1970" (italics mine), and that the values of the time fields in a "stat" structure are also times since the epoch. All definitions of "since" in the Webster's Third in my office indicate that it refers to times in the future of the associated event, so March 25, 1967, 18:00:00 GMT is not a time since the epoch and is not a value that "time" will return, nor is it a time that will appear in a "struct stat" time field. Assigning a meaning to negative "time_t" values may be straightforward in that it's done by replacing "since" with "before, at, or since"; however, it does involve changes to existing UNIX implementations to permit them to be interpreted as local times (even with table-driven time zone conversion routines, one has to get the tables right!). Few, if any, existing programs deliberately store negative values in "time_t" variables; many of those programs are likely to want to store times more than +/- 68 years from the epoch, so liberalizing the meaning of "time_t" isn't going to help them. They'll have to wait for the hypothetical time in the future when "time_t" is made a "long long int" or when all 32-bit machines have been replaced by 64-bit machines to make "time_t" useful to them. Volume-Number: Volume 6, Number 42
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (09/04/86)
From: hadron!jsdy@seismo.UUCP (Joseph S. D. Yao) Date: Tue, 2 Sep 86 04:14:29 edt Organization: Hadron, Inc., Fairfax, VA In article <5638@ut-sally.UUCP> you write: >From: elsie!ado@seismo.UUCP >While it's true that no UNIX files date back to before January 1, 1970, >there *are* uses for times before that epoch: in personnel data bases where >birth dates are recorded; in data bases recording astronomical events; >in stock market price data bases (as used by chartist fanatics); and elsewhere. These should be recorded in the DATE format of your DBMS, not as a longint! If your DBMS has no DATE format (tsk!), it should be recorded as three [or six] ints. Yes, I know you'll have to compare via a procedure instead of an op; see the (tsk!) above. >(And what of all those old 7094 executables that are being used on IBM machines >running UNIX or a cousin? :-)) What of them? >I see more use in the short run for being able to record times between >1901 and 1970 that I see for being able to record times after 2038. Possibly. But I plan to be living (and making plans) well into the 2000's. I don't want to run up against a wall. (I already have, in that versions of Unix today don't allow such dates, and I have -- I don't remember why! -- tried to use them.) In addition, you would not be "retaining" any capability -- the systems I know tend to turn negative dates into something on the order of: Sat Feb 5 01:28:16 2^A06 (This is -(60*60*24): the '^A' is, yes, a control-A.) Any date after 31 Dec 1999 up to some value >> 2^31 loses everything after the '2' in the year: I think the second char of the year is being converted to a control-@, or NUL character. (Results from 4BSD and Ultrix on VAX and 680x0 processors. I haven't tried this on the s5/VAX.) -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP} jsdy@hadron.COM (not yet domainised) Volume-Number: Volume 6, Number 43
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (09/06/86)
From: campbell%maynard.UUCP@HARVISR.HARVARD.EDU (Larry Campbell) Date: Fri, 5 Sep 86 01:51:09 EDT Organization: The Boston Software Works, Inc. >From: hadron!jsdy@seismo.UUCP (Joseph S. D. Yao) > >In addition, you would not be "retaining" any capability -- the systems >I know tend to turn negative dates into something on the order of: > Sat Feb 5 01:28:16 2^A06 > ... >(Results from 4BSD and Ultrix on VAX and 680x0 processors. I haven't >tried this on the s5/VAX.) For what it's worth, I tried several interesting values on my VENIX 2.0 (V7-based) system. It handles negative values "properly" (that is, it prints reasonable dates prior to 1970); for instance, 0xC0000000 yields "1935 Dec 23 05:22:56". And it also handles dates beyond 2000 correctly; 0x70000000 yields "2029 Jul 18 01:49:52". -- Larry Campbell The Boston Software Works, Inc. ARPA: campbell%maynard.uucp@harvard.ARPA 120 Fulton Street, Boston MA 02109 UUCP: {alliant,wjh12}!maynard!campbell (617) 367-6846 [ Depends on what you call broken. Another example where time values outside the currently supported (or proposed) range would be useful: some of us like to play with genealogical software; I have known ancestors back to the thirteenth century and frequently work with data to the sixteenth century. But time_t probably isn't the appropriate format to keep such dates, considering Julian vs. Gregorian calendars, old and new style new years, etc. -mod ] Volume-Number: Volume 6, Number 44
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (09/15/86)
From: cbosgd!cbosgd.ATT.COM!mark@seismo.UUCP (Mark Horton) Date: Wed, 10 Sep 86 12:40:40 edt Organization: AT&T Bell Laboratories, Columbus There are many uses for dates, on which you'd like to be able to do arithmetic. I don't see where the assumption that time_t is only useful for file modification times got made. We have an application that needs to be able to store birth dates of people living today, and of their parents. We would like to be able to use the same format for parents' birth dates and for machine generated time stamps. And we'd like to be able to easily add or subtract 3 hours, for example, from such a quantity. Note that all the UNIX routines to deal with dates, such as ctime, localtime, gmtime, and asctime, deal with time_t quantities. There are no operations provided to manipulate a struct tm. This means there's a huge penalty for any application that needs to manipulate times that might be before 1970 or after 2038. They must implement a set of primitives to manipulate a struct tm or other data structure (such as an ISO format time string, which is also broken into year, month, day, etc.) Even if you offered us dates back to 1901, it wouldn't be enough for our application. We have to go back to about 1850. But I would hope to see some facilities added to manipulate a more general date/time format than a time_t. Maybe the 4.2BSD struct timeval needs to have another field added to indicate a base year (defaulting to 1970.) Mark [ There are manipulation (adding, subtracting) routines for timeval in the 4.2BSD kernel, by the way, though they never seem to have been brought out into a user-accessible library, even in 4.3BSD (except for timerisset, timercmp, and timerclear in <sys/time.h>). -mod ] Volume-Number: Volume 6, Number 47
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (09/15/86)
From: mnetor!utzoo!dciem!msb@seismo.UUCP (Mark Brader) Date: Thu, 11 Sep 86 18:37:22 edt > Another example where time values outside the currently supported > (or proposed) range would be useful: some of us like to play with > genealogical software; I have known ancestors back to the thirteenth > century and frequently work with data to the sixteenth century. > But time_t probably isn't the appropriate format to keep such dates, > considering Julian vs. Gregorian calendars, old and new style new years, I would say that time_t WOULD be the appropriate format, for PRECISELY those reason, if the range was available. To say otherwise is to say that time_t is inappropriate for the way it's normally used because of time zones and daylight and standard time. [ Not precisely, since the form a date is recorded in may vary according to not only present location but national origin of the recorder or of the person whose date it is, since there are relatively odd formats (1617/18 is a common format, being used with a date between Jan 1 and Mar 15), since many dates are incomplete (e.g., only year is known), and since accuracy to the hour is very rare, not to even mention minutes or seconds. Incidentally, the Mormon Church is coordinating the development of something called GEDCOM (GEnealogical Data COMmunications), which is a genealogical data interchange format. (It looks rather like a network presentation layer to me, even resembling XDR a bit.) They must have produced some standard for genealogical dates. I believe I will write off for a copy for myself. The address (if anyone else is interested) is probably Genealogical Department Ancestral File Operations Unit 50 E. North Temple St. Salt Lake City, UT 84150 However, I suspect that general discussions on genealogy belong in another newsgroup, so submissions to mod.std.unix related to genealogy should probably be kept related to date formats or other implementation issues. -mod ] While I'm writing I must correct the common assertion that time_t represents a time in the UT (GMT) system. It doesn't. It represents a time in seconds from a certain epoch. The time in time_t form at the moment, for instance, is 526,841,748. The corresponding time in UT is 4:55:48 pm. Granted that the latter is derived from the former by slightly simpler arithmetic than is my local zone time, that doesn't mean that a time_t represents a time in UT in particular. I don't think this is of sufficient interest to post to mod.std.unix, but you may post any or all if you wish. Mark Brader, utzoo!dciem!msb If ... it seems easier to subvert UNIX systems than most other systems, the impression is a false one. The subversion techniques are the same. It is just that it is often easier to write, install, and use programs on UNIX systems than on most other systems, and that is why the UNIX system was designed in the first place. -- Frederick T. Grampp & Robert H. Morris Volume-Number: Volume 6, Number 48