Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!decwrl!pyramid!ut-sally!std-unix
From: std-unix@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: jsq@sally.UUCP

From: sun!gorodish!guy@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