Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!std-unix
From: std-u...@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: timezone implementation constraints
Message-ID: <5406@ut-sally.UUCP>
Date: Fri, 25-Jul-86 11:20:14 EDT
Article-I.D.: ut-sally.5406
Posted: Fri Jul 25 11:20:14 1986
Date-Received: Fri, 25-Jul-86 21:33:55 EDT
Organization: IEEE 1003 Portable Operating System for Computer Environments
Committee
Lines: 131
Keywords: 1003.1 A.3
Approved: j...@sally.UUCP
From: hplabs!hao!vianet!dev...@pyramid.UUCP (Bob Devine)
Date: Thu, 24 Jul 86 23:13:44 mdt
[ This is really not directly related to IEEE 1003.1, since
it solely discusses the details of an *implementation* and
says nothing about the *interface*. However, it does
address something which has been previously discussed
in this newsgroup, and I can't think of a better place for it.
However, please do detailed line-by-line discussions of this
through mail among interested parties.
Could we find a new topic?
-mod]
Arthur Olson's recent posting to mod.sources included the updated
settz data tables. This reply in mod.std.unix is to correct some
of the entries in the table and re-raise my points about what is the
best implementation. I believe everyone has agreed on Robert Elz's
direction for the POSIX document wording.
The lines beginning with "> " are from Arthur Olson.
> Bob Devine has written that ". . .your table is wrong for MostNA in 1974.
> The correct ending date is 10/27 not 11/24." Yet on a 4.1bsd VAX/11-750
> system, compiling and executing the program
> [[[ program omitted ]]]
> results in the output
> Fri Nov 1 22:40:00 1974
> isdst: 1
> For now we'll stay with 4.1bsd's version.
The date I gave is correct. Any version of Unix that uses 11/24 is
simply wrong. The dates for 1974 and 1975 DST rules are:
1974 1/6 to 10/27
1975 2/28 to 10/26
Even the source for Xenix V that I just checked has it wrong. Believe
me folks, this comes directly from Dept of Transportation. (If you are
wondering why DOT has responsibility for such info, drop me a line. BD)
> Note also this from munnari!kre:
> "I recall also being told by someone once that Canada didn't have
> the DST variations in 74/75 that the US did, but I am not nearly
> sure enough of this to add anything."
> If Canada or Mexico decide not to follow the US change in DST that takes
> effect in 1987, additions had best be made below.
Canada did not follow the fuel follies for '4 and '5.
Please split the rules *by country*, not by continent, to avoid such problems.
The "MostNA" rules listed are incorrect for Canada and Mexico!
> Before the Uniform Time Act of 1966 took effect in 1967, observance of
> Daylight Saving Time in the US was by local option, except during wartime.
This is the acid-test of all proposals for handling DST rules. When I
submitted my suggestion to mod.std-unix last February (that now seems like
the distant past), I used the most common way of representing the changes.
The reason was I had examined all the world-wide rules and after silently
tearing my hair out trying to come up with a small table, decided to
go with the only way that I had any hope of getting right. To represent
all of the worldwide rules for just +/- 5 years requires several hundred
lines. No speed would ever be possible for a full table. My way was to
just represent the current year. At best, that simple formula would work
for many years; at worst, changes can't be handled (which is why folks
did fall in love with it).
The US tried to standardize DST rules in that '66 Act. But, of course,
there are still many exceptions. Plus, checking dates prior to it is
painful. Now imagine how the US was before 1967 and apply that to the
world. You get the feeling of near chaos?
I have since come to the conclusion that the best way to represent
DST and timezone information is a single rule plus an "exceptions database".
Only if the simple rule doesn't work (e.g., past or future years, other
timezones) is the database used. This way, rules can be added as needed.
Or the entire database can be empty with the single rule used for all
conversions.
DST is almost like the (jeez, I forgot who said it) quote about the
universe "being more complicated that can be possibly imagined".
This is not an exact analogy, but, at least physical laws are controlled
by Congress!
># Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S
>Rule MostNA 1967 1973 - Apr lastSun 2:00 1:00 D
>Rule MostNA 1967 1973 - Oct lastSun 2:00 0 S
Note: the rules for 1967 - 1973 depend on what state/territory you are in.
For example, Michigan is an exception to the rule for 1969-72 but not for
1967-68. Eastern Indiana is another tricky one for this period. Again,
note that this is *after* the '66 Act that tried to standardize DST.
>Rule MostNA 1974 only - Jan 6 2:00 1:00 D
>Rule MostNA 1974 only - Nov 24 2:00 0 S
Should be ====> Oct 27
># New names
>Zone Newfoundland -3:30 - NST # Is DST now observed here?
># If so, when did it start?
Newfoundland observes DST by the same rules as the rest of Canada -- the
last Sunday in April to the last Sunday in October. It has followed this
pattern since 1951. Changeover time is 2am.
Saskatchewan is another matter...part in EST; part in CST which doesn't use DST.
># Nonstandard mainland areas:
These rules are impossible to formulate. The amazing variety of
different DST rules makes such a tabularizing absurd. The rules vary
by state, by regions within states, by areas that have not yet even
been admitted to the union, by county, by city, and seemingly by whim.
>Rule SomeUS 1918 1919 - Mar lastSun 2:00 1:00 D
>Rule SomeUS 1918 1919 - Oct lastSun 2:00 0 S
>Rule SomeUS 1942 only - Feb 9 2:00 1:00 W # War
>Rule SomeUS 1945 only - Sep 30 2:00 0 S
>
>Zone East-Indiana -5:00 SomeUS E%sT # Usually standard near South Bend
>Zone Arizona -7:00 SomeUS M%sT # Usually standard in Arizona
>
># And then there's Hawaii.
>Rule Hawaii 1947 only - Jun 8 2:00 0 S
The information I have does not show any DST changes in 1947. DST was
not observed in the period 1946-present.
Bob Devine
Volume-Number: Volume 6, Number 37
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!decwrl!pyramid!ut-sally!std-unix
From: std-u...@ut-sally.UUCP
Newsgroups: mod.std.unix
Subject: Re: timezone implementation constraints
Message-ID: <5422@ut-sally.UUCP>
Date: Sun, 27-Jul-86 00:35:36 EDT
Article-I.D.: ut-sally.5422
Posted: Sun Jul 27 00:35:36 1986
Date-Received: Sun, 27-Jul-86 05:04:06 EDT
Organization: IEEE 1003 Portable Operating System for Computer Environments
Committee
Lines: 66
Approved: j...@sally.UUCP
From: sun!gorodish!...@utastro.UUCP (Guy Harris)
Date: Sat, 26 Jul 86 17:19:08 PDT
> This is really not directly related to IEEE 1003.1, since
> it solely discusses the details of an *implementation* and
> says nothing about the *interface*.
There is one point, though, that is a concern of the interface; what times
can "localtime" convert and, more generally, what times can a "time_t"
represent? The P1003.1 standard refers to the definition of "localtime" in
the X3J11 C standard. That standard doesn't say anything about the meaning
of the value returned by "time". The P1003.1 standard defines it as UNIX
time, namely the number of seconds since January 1, 1970, 00:00 GMT.
Existing UNIX implementations at least make an attempt to convert times not
in the current year; programs such as "ls" depend on this. If the current
standard can be interpreted as permitting "localtime", etc. not to make
their best effort to convert times not in the current year, the proposal
must tighten the wording so that this is required. It may be possible to
permit "best effort" to mean "use this year's rules", although I suspect
people would not be at all happy with such an implementation. An
implementation must specify what sort of effort it will make to convert
times, so that if somebody doesn't want to get stuck with an implementation
that can't convert times outside the current year they can avoid them.
Obviously, times in the future can't be converted with absolute certainty.
There's not much point in worrying about the inability to predict future
changes to daylight savings time rules.
I suspect all the debates about conversion of times in 1947 may be
completely irrelevant, since the UNIX epoch starts in 1970. The use of the
word "since" indicates to me that only positive values of a "time_t" are
valid. Either the standard should require this, or should indicate that
"time_t" may be negative. I see no reason to permit negative values for
times; the difference *between* times can, however, be negative. As such,
if "time_t" is to be used in programs for P1003.1 systems to represent the
difference between two times, it should not be an unsigned type. If one
restricts times (as opposed to time differences) to be positive, the largest
possible differences (both positive and negative) between two times will fit
in a "time_t".
I propose that:
1) the specification of "time" should be tightened to indicate
that it will not return a negative value.
2) the specification of "stat" should also indicate that the
modification, access, and inode-change times shall never
be negative.
3) the "utime" call be required to return EINVAL if an attempt
is made to set the access or modification times of a file
to negative values.
If "time" is to return a valid time value, it will never return a negative
value since 1970 has already passed. Since UNIX came out in 1971, if "stat"
or "fstat" were to return a valid time value for access, modification, or
inode-change time, it will never be negative since there weren't UNIX
systems (or any other flavor of P1003.1-compliant system) before 1970.
Thus, the only way times can be negative are if the system clock is set to a
negative value - since P1003.1 specifies no system call to set the system
clock, this is out of its control, although a caveat about this should
perhaps be included - or if "utime" is used to set the clock to such a
value, which P1003.1 can forbid.
Volume-Number: Volume 6, Number 38