home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v6 / text0041.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  2.8 KB
  1. From: sun!gorodish!guy@utastro.UUCP (Guy Harris)
  2. Date: Sat, 30 Aug 86 20:39:06 PDT
  3.  
  4. > While it's true that no UNIX files date back to before January 1, 1970,
  5. > there *are* uses for times before that epoch:
  6.  
  7. Yes, but there are other representations for such dates and times; there's
  8. no particular need to have "time_t" objects represent dates in 4004 BCE, for
  9. example.  Most of the time, they are represented as mixed-radix numbers,
  10. giving year, month, day, etc., or year, day of year, etc..  The standard
  11. arithmetic functions on dates (date1 - date2, date1 + offset, etc.) are
  12. possible, if slightly less convenient, as are comparisons of dates.  Most of
  13. the examples given don't currently use "time_t", as they're not done on UNIX
  14. systems, and there's no good reason to change them and not much reason to
  15. use "time_t" for future programs of those sorts.  ("time_t" is an especially
  16. poor choice for astronomical event databases; many interesting such events
  17. occurred more than 68 years before 1970....)
  18.  
  19. > I see more use in the short run for being able to record times between
  20. > 1901 and 1970 that I see for being able to record times after 2038.
  21.  
  22. Yes, but is there a use for recording UNIX file modification times between
  23. 1901 and 1970?  Other times can be recorded in forms other than a "time_t".
  24.  
  25. > In summary:  I'd recommend retaining the ability for time_t variables to
  26. > represent times before 1970.
  27.  
  28. It's not a case of "retaining".  The 1003.1 Trial-Use Standard says that the
  29. result of "time" represents "the value of times in seconds *since* 00:00:00
  30. GMT, January 1, 1970" (italics mine), and that the values of the time fields
  31. in a "stat" structure are also times since the epoch.  All definitions of
  32. "since" in the Webster's Third in my office indicate that it refers to times
  33. in the future of the associated event, so March 25, 1967, 18:00:00 GMT is
  34. not a time since the epoch and is not a value that "time" will return, nor
  35. is it a time that will appear in a "struct stat" time field.
  36.  
  37. Assigning a meaning to negative "time_t" values may be straightforward in
  38. that it's done by replacing "since" with "before, at, or since"; however, it
  39. does involve changes to existing UNIX implementations to permit them to be
  40. interpreted as local times (even with table-driven time zone conversion
  41. routines, one has to get the tables right!).  Few, if any, existing programs
  42. deliberately store negative values in "time_t" variables; many of those
  43. programs are likely to want to store times more than +/- 68 years from the
  44. epoch, so liberalizing the meaning of "time_t" isn't going to help them.
  45. They'll have to wait for the hypothetical time in the future when "time_t"
  46. is made a "long long int" or when all 32-bit machines have been replaced by
  47. 64-bit machines to make "time_t" useful to them.
  48.  
  49. Volume-Number: Volume 6, Number 42
  50.  
  51.