Berkeley variant of time zone stuff
Sat Feb 25 02:52:01 UTC 2012
The folks at Berkeley have posted a slight variant of the recent mod.sources
time zone posting to comp.bugs.4bsd.ucb-fixes. I'd like to note some of the
differences, comment on the differences, and ask for opinions on what to
do with Berkeley's changes.
1. Berkeley has dropped the "tzsetwall" function.
You call tzsetwall to arrange for "localtime" to deliver the best available
approximation to local wall clock time.
Berkeley's approach is to provide
an "unsetenv" function so that folks can do an
call before calling localtime; since the mod.sources version of the time
zone stuff uses local wall clock time if TZ is absent from the environment,
this has the desired effect. As Keith Bestic (:-)) notes, this also has
the advantage of arranging for forked-off processes to run on local wall
The disadvantage I see here is in porting code to old systems.
Take, for example, "sysdate.c", which is designed to print out
the system's idea of wall clock time regardless of what the user has
set TZ to (potentially useful when calling a system in Paris from Podunk):
extern char * ctime();
char * argv;
(void) printf("%s", ctime(&now));
Now suppose this code lands on a System V Release 2 machine.
Our hypothetical code porter tries to compile it and gets an
diagnostic. The porter then goes ahead and implements unsetenv,
and things compile just fine--but when "sysdate" is run, it spits
out GMT, which is what System V Release 2 does when TZ is absent from
Is Berkeley's "unsetenv" approach the right one to take to give processes
a way of guaranteeing that they run on local wall clock time? Is
"tzsetwall" the way to go? Is there some other, better approach?
2. The mod.sources version of "tzset" tries to load up the time zone
information specified in the TZ environment variable; if this fails,
it sets things up so that GMT is used. The comp.bugs.4bsd.ucb-fixes
tries to load up the time zone information specified by TZ;
if that fails, tries to load up "localtime";
if *that* fails, tries to load up information based
on what a "gettimeofday" system call returns;
and if *that* fails, loads up GMT.
First, it would seem to me that having two ways of specifying what local
time should be--the /etc/zoneinfo/localtime file, and the results of a
gettimeofday system call--is a bad idea. Is there a good reason for
keeping the gettimeofday (and settimeofday) system calls?
Should the time zone stuff include a replacements for gettimeofday?
For settimeofday? Should gettimeofday and settimeofday be unceremoniously
Second, what about the notion of trying for localtime (before defaulting
to GMT) if the TZ environment variable contains something nonsensical?
I eventually decided against trying for local time; it makes for (very
marginally) simpler code, and I thought that (for US users at least)
getting dates reported in GMT would be likelier to serve notice that
something was wrong with the TZ variable.
3. Berkeley forged ahead and added the "tm_gmtoff" and "tm_zone" elements to
the tm structure.
4. Berkeley retained the "solar87" file but in their default distribution
it doesn't get compiled (and defines used in localtime and friends are
not set up to allow its use); the mod.sources posting does compile the
solar87 file (and defines things so that it can be used) unless you
take steps otherwise. Is the Berkeley approach best here?
More information about the tz