home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v6 / text0037.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  3.4 KB
  1. From: sun!gorodish!guy@utastro.UUCP (Guy Harris)
  2. Date: Sat, 26 Jul 86 17:19:08 PDT
  3.  
  4. > This is really not directly related to IEEE 1003.1, since
  5. > it solely discusses the details of an *implementation* and
  6. > says nothing about the *interface*.
  7.  
  8. There is one point, though, that is a concern of the interface; what times
  9. can "localtime" convert and, more generally, what times can a "time_t"
  10. represent?  The P1003.1 standard refers to the definition of "localtime" in
  11. the X3J11 C standard.  That standard doesn't say anything about the meaning
  12. of the value returned by "time".  The P1003.1 standard defines it as UNIX
  13. time, namely the number of seconds since January 1, 1970, 00:00 GMT.
  14.  
  15. Existing UNIX implementations at least make an attempt to convert times not
  16. in the current year; programs such as "ls" depend on this.  If the current
  17. standard can be interpreted as permitting "localtime", etc. not to make
  18. their best effort to convert times not in the current year, the proposal
  19. must tighten the wording so that this is required.  It may be possible to
  20. permit "best effort" to mean "use this year's rules", although I suspect
  21. people would not be at all happy with such an implementation.  An
  22. implementation must specify what sort of effort it will make to convert
  23. times, so that if somebody doesn't want to get stuck with an implementation
  24. that can't convert times outside the current year they can avoid them.
  25.  
  26. Obviously, times in the future can't be converted with absolute certainty.
  27. There's not much point in worrying about the inability to predict future
  28. changes to daylight savings time rules.
  29.  
  30. I suspect all the debates about conversion of times in 1947 may be
  31. completely irrelevant, since the UNIX epoch starts in 1970.  The use of the
  32. word "since" indicates to me that only positive values of a "time_t" are
  33. valid.  Either the standard should require this, or should indicate that
  34. "time_t" may be negative.  I see no reason to permit negative values for
  35. times; the difference *between* times can, however, be negative.  As such,
  36. if "time_t" is to be used in programs for P1003.1 systems to represent the
  37. difference between two times, it should not be an unsigned type.  If one
  38. restricts times (as opposed to time differences) to be positive, the largest
  39. possible differences (both positive and negative) between two times will fit
  40. in a "time_t".
  41.  
  42. I propose that:
  43.  
  44.     1) the specification of "time" should be tightened to indicate
  45.        that it will not return a negative value.
  46.  
  47.     2) the specification of "stat" should also indicate that the
  48.        modification, access, and inode-change times shall never
  49.        be negative.
  50.  
  51.     3) the "utime" call be required to return EINVAL if an attempt
  52.        is made to set the access or modification times of a file
  53.        to negative values.
  54.  
  55. If "time" is to return a valid time value, it will never return a negative
  56. value since 1970 has already passed.  Since UNIX came out in 1971, if "stat"
  57. or "fstat" were to return a valid time value for access, modification, or
  58. inode-change time, it will never be negative since there weren't UNIX
  59. systems (or any other flavor of P1003.1-compliant system) before 1970.
  60. Thus, the only way times can be negative are if the system clock is set to a
  61. negative value - since P1003.1 specifies no system call to set the system
  62. clock, this is out of its control, although a caveat about this should
  63. perhaps be included - or if "utime" is used to set the clock to such a
  64. value, which P1003.1 can forbid.
  65.  
  66. Volume-Number: Volume 6, Number 38
  67.  
  68.