Berkeley variant of time zone stuff

Keith Bostic seismo!berkeley.edu!bostic%okeeffe
Thu Apr 2 21:39:03 UTC 1987


> Point taken; clearly the gettimeofday system call must be retained
> (which implies that settimeofday has to hang around too)
> to help out old binaries.

More importantly, it has to be retained for better than second
resolution.

> Or "/etc/TIMEZONE".  S5R3.1 currently has "init" load up the
> environment from what's in "/etc/TIMEZONE".  Presumably, you could
> have "defaultzone" read the setting of TZ from this...
> 
> 	or generate a string from the abbreviations and other
> 	information stored in the "/etc/zoneinfo/localtime" file.
> 
> or generate that string.
> 
> 	But there doesn't seem to be any way to get
> 		unsetenv("TZ")
> 	(the Berkeley posting approach) to give the desired effect of
> 	getting your process--and any children that it later forks
> 	off--running on local wall clock time.  If you take that approach
> 	on a System V system, and then fork off an "old" binary, the old
> 	binary will end up using GMT.
> 

I'm sorry, but I'm not following this whole discussion.  It seems to
me that S5 has the problem here; BSD offers two different ways to
guarantee that "localtime" is used, setenv("localtime") and unsetenv("TZ").
S5 has no way (does it?) to do so.  Adding another way to BSD won't
help the situation.  Now, if S5 wanted to add something, I could
understand wanting to add it to BSD.

> That's why I suggested the "defaultzone" routine - you need some
> portable way of setting the TZ environment variable; given existing
> systems, removing it isn't a portable way of forcing local wall clock
> time.

To make this portable, you'll have to alter S5, right?

--keith



More information about the tz mailing list