Tech Insider					     Technology and Trends

			      USENET Archives

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 
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?

  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

  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	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 
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

			        About USENET

USENET (Users’ Network) was a bulletin board shared among many computer
systems around the world. USENET was a logical network, sitting on top
of several physical networks, among them UUCP, BLICN, BERKNET, X.25, and
the ARPANET. Sites on USENET included many universities, private companies
and research organizations. See USENET Archives.

		       SCO Files Lawsuit Against IBM

March 7, 2003 - The SCO Group filed legal action against IBM in the State 
Court of Utah for trade secrets misappropriation, tortious interference, 
unfair competition and breach of contract. The complaint alleges that IBM 
made concentrated efforts to improperly destroy the economic value of 
UNIX, particularly UNIX on Intel, to benefit IBM's Linux services 
business. See SCO vs IBM.

The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or

Electronic mail:			       WorldWideWeb: