home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v6 / text0033.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  4.9 KB
  1. From: ll-xn!s3sun!sdcsvax!ncr-sd!greg.@topaz.UUCP
  2. Date: Fri, 18 Jul 86 15:47:39 PDT
  3. Organization: NCR Corporation, Rancho Bernardo
  4.  
  5. Some comments about the timezone proposal to be submitted to P1003.
  6. This is mostly nitpicking, but there are some loose ends that such
  7. a proposal will need to specify.  I will comment from Elz's text;
  8. the text of the proposal to P1003 follows this wording closely.
  9.  
  10. In article <5352@ut-sally.UUCP> Robert Elz writes:
  11. >localtime: converts the time_t "*t" to a "struct tm" representing
  12. >the given time adjusted to represent some local time difference.
  13. >"local time" will be specified by a call to "settz", if no such
  14. >call has preceded the call to localtime(), localtime() will call
  15. >"settz(getenv("TZ"));".  ........
  16.  
  17. Note that this implies that there must be some way for the implementation
  18. to tell (a) if settz has been previously called, and presumably, (b) what
  19. value was provided by settz.  This information should be part of the
  20. interface.  It is easy to imagine a utility logging subroutine that would
  21. want to use the local time when inserting log entries without disturbing
  22. other time-display calculations (the user might be running in a different
  23. time zone), so this logging subroutine will need to be able to set and
  24. potentially reset the time zone information.
  25.  
  26. [ Perhaps.  The assumption is that a process will either use the
  27. same variety of localtime throughout, or that it will explicitly
  28. set the kind it wants with settz before using localtime.
  29. That still leaves the question of how localtime knows settz
  30. has been used previously, but as long as it does, it's
  31. not clear that an application writer needs to know how
  32. it's done.  -mod ]
  33.  
  34. >If settz is called with an unrecognisable argument, the effect
  35. >is implementation defined.  (Users might expect any of three
  36. >"reasonable"? actions could be taken here -- use GMT, use local time,
  37. >or use local time in the area where the implementation was performed).
  38.  
  39. Since I have been bitten too many times by having the default time zone
  40. be that of the implementers, I feel that option three is unreasonable.
  41. Presumably, since an attempt was made to set the time zone to a non-local
  42. value, using GMT as a canonical non-local time zone is probably reasonable
  43. (for everybody except those in England, of course -- perhaps it should be
  44. called UCT when in this mode so as not to use the same abbreviation).
  45.  
  46. [ This is an example of something you'll find throughout 1003.1:
  47. an attempt to not outlaw existing behavior of existing systems.
  48. If option three were not included (ugly as it is), I doubt the committee
  49. would be able to reach consensus on including settz.  -mod ]
  50.  
  51. >What's missing:  So far here there is no mention of the "timezone name".
  52. >None of the standard mechanisms is really adequate here.  ......
  53. >Arthur Olson's scheme causes "localtime" to set a global variable
  54. >"tz_abbr" to the correct string name for the timezone just used.
  55.  
  56. I propose an extension of the System V mechanism.  That interface defines
  57. "extern char *tzname[2]" for the time zone names and has a field in the
  58. tm struct (tm_isdst) that is non-zero if daylight savings is in effect;
  59. i.e., the current timezone name is tzname[tm.tm_isdst != 0].  I propose
  60. that the standard add "extern char *tzname[]" (note that the length is
  61. not specified; the bound would be implementation-defined) and have wording
  62. that says that tzname[tm.tm_isdst] is the name of the relevant timezone.
  63. Since the current System V implementation only sets tm_isdst to zero or
  64. one, this is actually backward compatible.  (In fact, I just looked through
  65. our System V sources for uses of tzname; most of the uses are of the latter
  66. form rather than the former, so this proposal is even more compatible than
  67. it looks.)
  68.  
  69. >....[problems simulating BSDs "timezone()" function] - one might be to
  70. >retain "timezone" but not require that it be capable of returning
  71. >anything except the zone name corresponding to the last call of
  72. >localtime()  .......
  73.  
  74. With the above proposal, "timezone()" would return values selected from
  75. the tzname array if the time zone was one covered by the last settz(), or
  76. otherwise return a string of the form "+-hhmm".  This function probably
  77. should not be part of the standard, since it is primarily present for
  78. backward compatibility.  If it is present, it should be depreciated so
  79. that it can go away in the future.
  80.  
  81. And while we're on backward compatibility, the SysV function tzset() could
  82. be defined as "if(timezone_not_set) settz(getenv("TZ");" to be compatible
  83. with the way it currently works; again, if this function is defined, its
  84. usage should be depreciated.
  85.  
  86. [ I don't think tzset is in the standard, but that's a useful implementation
  87. note.  -mod ]
  88.  
  89. System V also defines external variables for the current timezone and daylight
  90. savings rule.  Are there any programs that actually use these?  Should they be
  91. part of the interface as well?  (Or some equivalent functionality?)
  92.  
  93. -- 
  94. -- Greg Noel, NCR Rancho Bernardo    Greg@ncr-sd.UUCP or Greg@nosc.ARPA
  95.  
  96.  
  97. Volume-Number: Volume 6, Number 34
  98.  
  99.