Re: timezone proposals for P1003
Just a brief note on history; Robert points out, quite correctly, that the 4BSD timezone() function, use of ftime, and so on, all date back to V7. I just wanted to point out that the System V convention of the external variables "timezone" and "daylight" date back to V6, essentially untouched. V6 did not have ftime, the TZ environment variable (or environments at all), nor tzset. I'm not sure how it knew the local time zone; I don't believe the date command, or any other piece of software, produced a time zone name, but I think timezone and daylight were statically compiled into libc, and you had to relink the system if you installed it anywhere except the USA Eastern zone. Thus, the conflict between the timezone external integer, and the timezone function, seems to have been introduced by Bell Labs 127 group, sometime between V6 and V7. This conflict will make life interesting for any implementations striving for upward compatiblity with both systems. As far as I am able to determine, neither X3J11 nor POSIX requires either, but of course the SVID requires the integer. This suggests that it would be nice if Berkeley phased out the function. Mark
Groan, yes I'd forgotten the v6 timezone - though it was an int, not a long, which caused all kinds or problems for Australians with 16 bit processors (I ran v6 on a 32 bit machine, so it disn't bother me). The problem was that you can't put -36000 in a 16 bit int... I believe that date(1) did print a zone name, but that it was compiled in. v7 made a bunch more incompatibilities than this one, the change in the meaning of the external "timezone" wasn't such a serious one. I have no doubt that getting bsd to drop the timezone function won't be a problem, once some respectable (agreed) way to replace it is found. kre
participants (2)
-
Robert Elz -
seismo!cbpavo.MIS.OH.ATT.COM!mark