Path: utzoo!mnetor!uunet!husc6!think!ames!oliveb!sun!gorodish!guy
From: guy@gorodish.Sun.COM (Guy Harris)
Newsgroups: comp.unix.aux
Subject: Re: gettimeofday()
Message-ID: <51482@sun.uucp>
Date: 1 May 88 21:29:16 GMT
References: <930@unisoft.UUCP> <51320@sun.uucp> <936@unisoft.UUCP>
Sender: news@sun.uucp
Lines: 44

> >1) Could not "gettimeofday()" have a static flag that indicates whether it's
> >   called "tzset()" or not, so that only the first call to "gettimeofday()"
> >   calls "tzset()"?
> 
> actually it ought to read it, maybe not everytime but at least once every
> 10-15 minutes (think of a server daemon - like CAP aufs etc that runs for
> potentially months or years at a time)) just in case the timezone changed
> (ie those two times twice a year when the daylight-saving changes)

It appears that either 1) you aren't really running the Olson code or 2) don't
understand how the Olson code works.  The timezone *file* only changes if the
government goes bananas and changes the *rules*.  It does *not* change twice a
year.

The "timezone" structure in 4.[23]BSD provides two pieces of information:

	1) the *standard* offset from GMT; this does *not* change when DST
	   starts or ends.  For example, it's hardwired to 8 hours here.

	2) a small integer indicating the set of DST rules to follow.

(The latter obviously cannot always be reconstructed from the information in
the Olson time zone file.  It selects one of a set of hard-coded rule tables;
if the current rules match none of the tables, you lose.

What we will do in SunOS 4.0 is run a program at boot time that finds the
appropriate value for the standard offset and the "best" value of the small
integer, given the current default time zone rules, and does a "settimeofday"
call (with the first argument a NULL pointer; this sets the time zone
information and leaves the time-of-day information alone) to stuff those into
the kernel.  This permits old programs to work as well as they would have under
older versions of the systems; they won't, of course, be able to use the
greater flexibility of the Olson scheme.)

If you return the standard (non-changing, barring e.g. an earthquake dislodging
the stuff west of the San Andreas and sending it many thousands of miles west)
offset from GMT in the "tz_minuteswest" field, this obviously doesn't change
twice a year.

If, instead, you return the current offset from GMT, and return 0 in the
"tz_dsttime" field (i.e., pretend that DST is never in effect, but that the
standard offset changes twice a year), you still need not reread the file twice
a year; you just recompute the offset from GMT at the current time, using the
rules you've already read in, and return that.