Daylight Savings Time

[Steve Summit]

I hope nobody minds this on net.lang.c, but it was prompted by
several discussions there.

Somebody ought to do something more general about Unix time
conversion soon, precisely because of the fact that political
discussions are likely to continue to alter the algorithm.  The
state of Oregon has already decreed that Daylight Savings time is
to start two weeks earlier and end two weeks later next year.  I
don't know what Unix sites in Oregon are planning to do.

Although ctime has gotten pretty clever lately, under the
auspices of our friends at Berkeley, it will never be able to
predict the future.  It's folly to have to recompile every
program that uses ctime every time the DST algorithm changes.

Howard Johnson at Cyb Systems has already mentioned what I've
been meaning to propose, namely that "This is yet another
application crying out for some kind of dynamic link editor."
In fact, in this case, it doesn't even have to be that difficult.
As the current 4.2 documentation for ctime points out,

	"The program knows about various peculiarities in time
	conversion over the past 10-20 years; if necessary, this
	understanding can be extended."

The 4.2 implementation of ctime (actually localtime) is driven by
a single C data structure describing what the "peculiarities" of
the conversion were for various years.  Dynamically linking in a
single data object like this is quite easy: nroff has been loading
the terminal driving tables that way for years.  In fact, since
the information is tabular and not algorithmic, it would be
possible to store the information in a human-readable text file. 
However, a compiled form would probably be preferable in order to
silence the inevitable complaints from those who will maintain
that reading and parsing a file off of disk is too time-consuming
every time ctime (actually, localtime) is called.

It's too bad that 4.3 will be out so soon -- there probably isn't
time to get this in.

                                         Steve Summit
                                         textronix!copper!stevesu

P.S. for people who don't understand what the problem is:

Unix keeps Greenwich Mean Time, and it is up to a program,
running in user mode, to convert GMT to local time, by adding and
subtracting the correct timezone and daylight savings time
corrections.  This conversion is usually done using the routines
described under ctime in chapter 3 of the Unix Programmer's
Manual.  These routines take the Greenwich Mean Time, adjust it
by the time zone, and figure out what time of year it is.  If
it's a time of year that DST applies in, and if DST applies at
all, an additional hour is added.  (Or is it subtracted? -- I can
never remember.)

What timezone to use, and whether DST applies at all where the
machine is installed, is determined using the ftime() system call
(gettimeofday on 4.2bsd).  The timezone and DST flags are
compiled into the kernel (or hopefully user-settable on newer,
binary distribution systems).

Contrary to some implications made in some previous
articles on this subject, it is not necessary to make some
adjustment every six months to tell the system, "now start doing
daylight savings time -- now don't."  The decision is always
based on the global flags, and on the time being converted (_n_o_t
the current time).  For instance, if I do an ls -l on a file I
modified last summer, the modification time shown should be
reported the same even though DST doesn't apply right now.