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