>>While DST is not directly part of the C language, some of the libraries
that come with compiler and perhaps the C standard itself include
references to DST. How will the community react to the new federal law
extending DST into November in the year 2007? What should developers
be ready to do? How do foreign countries/developers use DST in their
present systems?
My instinct would be to use the Arthur Olson timezone package,
which provides a configurable database of what "Savings Time" consists
of where (and when). For example it already knows about the early-70's US
savings-times variants.
For those systems that already use this package (including, I
believe, Linux, various variants of BSD, OSF, etc.) all you have
to do is add an appropriate line to the text form of the time zone
description, set an end date for the current line, and compile it
with 'zic'. Well, it's a little more complicated than that if you
are trying to fix all time zones and not just the local (presumably
in the US) one. Existing C code need not be recompiled. Code that
does its own calculations for DST will need to be changed, but there
likely isn't much of that required.
HOWEVER, there are problems lurking around. If you have an application
that has stored future time_t stamps (which are represented in GMT
on systems using this package), after the date the original switchover
would have happened, they no longer represent the same local time
you think they did. That doctor's appointment you set up for 2:00PM
October 31, 2007 has shifted by an hour in your appointment calendar.
If, on the other hand, the date was stored as '2007-10-31 14:00:00'
(implicitly local time), there wouldn't be a problem.
Now: what happens if Canada does not go along with this change?
Gordon L. Burditt
