Usenet 1994 October/usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso/std_unix/moretz

Internet Message Format | 1988-02-09 | 45KB

From news  Mon Sep 29 13:52:45 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Summary of Volume 6 of mod.std.unix
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 29 Sep 86 18:52:17 GMT
Draft-9: mod.std.unix
Status: R

Administrativia:    N1, N13b, N51
mod.std.unix & P1003:    N2
Publicity:        N6
Access to standards:  N7, N10, N11, N12, N13a, N21, N22, N26, N27, N40, N46, N50
Access to user groups and publications:  N11, N21, N40, N45
POSIX Conformance Workshop:    N20
P1003.2 Shell Working Group:    N24, N25 (Hal Jespersen)
IEEE 1003.1, POSIX, & ISO/TC97:    N49 (Isaak)
RFCs:            N16 (jbc, jsq)

write EOF:        N5, N8, N9
tape file marks:    N14
ioctl vs. iocntl (and fcntl):  N15 (Smith, jbc), N17 (jbc), N18 (rbj), N19 (dag)
mkdir & rmdir implementation:  N23 (jsq, dag), N28 (dag)

Timezones:
    motivation:  N3 (Horton); location:  N4 (dag);  past:  N4 (jsq)

RFC.001:  Timezones:  N29 (jsq)
    RFC.001 Summary of mod.std.unix Volume 5:  N30 (jsq)
    RFC.001 Timezone Interface:  N31 (Elz)
    RFC.001 Timezone Examples:  N32 (Olsen)
    RFC.001 Timezone Proposal:  N33 (jsq)

Responses to RFC.001:
    Previous call on settz():  N34 (Noel), N36 (Elz)       (perhaps add)
    Implementor's TZ a bad default:  N34 (Noel), N36 (Elz)          (add note)
    Method to retrieve TZ name:  N34 (Noel), N36 (Elz)      (not tzname[])
    BSD timezone():  N34 (Noel)
    tzset() of System V:  N34 (Noel), N36 (Elz)      (implement, don't add)
    TZ & DST rule:  N34 (Noel), N35 (Horton), N36 (Elz)(can't be done right)
    Details of Olsen's implementation:  N37 (Devine)
The parenthetical comments at the far right indicate my interpretation
of the outcome of the discussions on the various topics and what I
recommended the committee do.

What does time_t represent and localtime() convert?  N38 (Harris)
*    unsigned for future:  N39 (Franklin), N42 (Harris), N43 (Yao)
    signed for past:  N41 (Olsen)
    an implementation:  N44 (Campbell)

Far Past:  N46 (jsq)
*    different representation:  N44 (jsq, genealogy), N47 (Horton)
    use time_t:  N48 (Brader)

* indicates the side of the discussion that won, as I see it.

Abbreviations:
    Brader:        Mark Brader
    Campbell:    Larry Campbell
    dag:        Douglas A. Gwyn
    Devine:        Bob Devine
    Elz:        Robert Elz
    Franklin:    Dan Franklin
    Harris:        Guy Harris
    Horton:        Mark Horton
    Isaak:        James Isaak (P1003 co-chair)
    jbc:        John B. Chambers (guest moderator)
    Jespersen:    Hal Jespersen (P1003.2 co-chair)
    jsq:        John S. Quarterman (moderator)
    Noel:        Greg Noel
    Olsen:        Arthur Olsen
    rbj:        Root Boy Jim Cottrell
    Smith:        Roy Smith
    Yao:        Joe Yao

Volume-Number: Volume 7, Number 7

From jsq  Sat Jul 19 12:37:44 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: RFC.001 Timezone Interface
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
In-Reply-To: <[e-mail]>
Date: 19 Jul 86 17:36:06 GMT
Draft-9: TZ.RFC.001
Status: R

From: ll-xn!s3sun!sdcsvax!ncr-sd![e-mail]
Date: Fri, 18 Jul 86 15:47:39 PDT
Organization: NCR Corporation, Rancho Bernardo

Some comments about the timezone proposal to be submitted to P1003.
This is mostly nitpicking, but there are some loose ends that such
a proposal will need to specify.  I will comment from Elz's text;
the text of the proposal to P1003 follows this wording closely.

In article <[e-mail]> Robert Elz writes:
>localtime: converts the time_t "*t" to a "struct tm" representing
>the given time adjusted to represent some local time difference.
>"local time" will be specified by a call to "settz", if no such
>call has preceded the call to localtime(), localtime() will call
>"settz(getenv("TZ"));".  ........

Note that this implies that there must be some way for the implementation
to tell (a) if settz has been previously called, and presumably, (b) what
value was provided by settz.  This information should be part of the
interface.  It is easy to imagine a utility logging subroutine that would
want to use the local time when inserting log entries without disturbing
other time-display calculations (the user might be running in a different
time zone), so this logging subroutine will need to be able to set and
potentially reset the time zone information.

[ Perhaps.  The assumption is that a process will either use the
same variety of localtime throughout, or that it will explicitly
set the kind it wants with settz before using localtime.
That still leaves the question of how localtime knows settz
has been used previously, but as long as it does, it's
not clear that an application writer needs to know how
it's done.  -mod ]

>If settz is called with an unrecognisable argument, the effect
>is implementation defined.  (Users might expect any of three
>"reasonable"? actions could be taken here -- use GMT, use local time,
>or use local time in the area where the implementation was performed).

Since I have been bitten too many times by having the default time zone
be that of the implementers, I feel that option three is unreasonable.
Presumably, since an attempt was made to set the time zone to a non-local
value, using GMT as a canonical non-local time zone is probably reasonable
(for everybody except those in England, of course -- perhaps it should be
called UCT when in this mode so as not to use the same abbreviation).

[ This is an example of something you'll find throughout 1003.1:
an attempt to not outlaw existing behavior of existing systems.
If option three were not included (ugly as it is), I doubt the committee
would be able to reach consensus on including settz.  -mod ]

>What's missing:  So far here there is no mention of the "timezone name".
>None of the standard mechanisms is really adequate here.  ......
>Arthur Olson's scheme causes "localtime" to set a global variable
>"tz_abbr" to the correct string name for the timezone just used.

I propose an extension of the System V mechanism.  That interface defines
"extern char *tzname[2]" for the time zone names and has a field in the
tm struct (tm_isdst) that is non-zero if daylight savings is in effect;
i.e., the current timezone name is tzname[tm.tm_isdst != 0].  I propose
that the standard add "extern char *tzname[]" (note that the length is
not specified; the bound would be implementation-defined) and have wording
that says that tzname[tm.tm_isdst] is the name of the relevant timezone.
Since the current System V implementation only sets tm_isdst to zero or
one, this is actually backward compatible.  (In fact, I just looked through
our System V sources for uses of tzname; most of the uses are of the latter
form rather than the former, so this proposal is even more compatible than
it looks.)

>....[problems simulating BSDs "timezone()" function] - one might be to
>retain "timezone" but not require that it be capable of returning
>anything except the zone name corresponding to the last call of
>localtime()  .......

With the above proposal, "timezone()" would return values selected from
the tzname array if the time zone was one covered by the last settz(), or
otherwise return a string of the form "+-hhmm".  This function probably
should not be part of the standard, since it is primarily present for
backward compatibility.  If it is present, it should be depreciated so
that it can go away in the future.

And while we're on backward compatibility, the SysV function tzset() could
be defined as "if(timezone_not_set) settz(getenv("TZ");" to be compatible
with the way it currently works; again, if this function is defined, its
usage should be depreciated.

[ I don't think tzset is in the standard, but that's a useful implementation
note.  -mod ]

System V also defines external variables for the current timezone and daylight
savings rule.  Are there any programs that actually use these?  Should they be
part of the interface as well?  (Or some equivalent functionality?)

--
-- Greg Noel, NCR Rancho Bernardo    [e-mail] or [e-mail]


Volume-Number: Volume 6, Number 34

From jsq  Mon Jul 21 08:46:20 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: RFC.001 Timezone Interface
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
In-Reply-To: <[e-mail]>
Date: 21 Jul 86 13:46:02 GMT
Draft-9: TZ.RFC.001
Status: R

Date: Mon, 21 Jul 86 01:23:29 edt
From: im4u!caip![e-mail] (Mark Horton)
Organization: AT&T Bell Laboratories, Columbus

>System V also defines external variables for the current timezone and daylight
>savings rule.  Are there any programs that actually use these?  Should they be
>part of the interface as well?  (Or some equivalent functionality?)

Yes, there's an important use.  If you're generating an RFC 822 compatible
>Date: line, you need to know the local offset from GMT or the time zone
name.  You can't just plug in the time zone name, because only the names
in the USA are allowed by 822, and if you try to extend that to the rest
of the world, you run into ambiguities.  In general, you can't assume that
someone in an arbitrary location in the world will understand your local
name for your time zone.  So you have to generate a zone like "+hhmm".

One might even claim that, in a zone like Japan, asking for the time zone
name should return "+0900" rather than "JST".  Probably not, but it's
a thought.

    Mark

Volume-Number: Volume 6, Number 35

From jsq  Tue Jul 22 20:01:34 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: RFC.001 Timezone Interface
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 23 Jul 86 01:00:55 GMT
Draft-9: TZ.RFC.001
Status: R

Date: 23 Jul 86 08:38:34 +1000 (Wed)
From: Robert Elz <munnari![e-mail]>

I have (more than) a few comments about some comments
about the timezone proposal.

[ There's only one comment from the moderator in this article:
discussions are very useful, but to get in the standard it needs
exact wording.  In other words, anyone wanting changes to the
proposal form I posted should supply *exact wording changes*.
(An alternative would be to submit a complete new proposal.)
-mod ]

Quotes until stated otherwise are from Greg Noel (ncr-sd!greg)...

> Note that this implies that there must be some way for the implementation
> to tell (a) if settz has been previously called, and presumably, (b) what
> value was provided by settz.

I agree, I hadn't considered this.  However, its essential that when
there's an interface that sets some static state, there be some means
to determine the current value of that state - I've been frustrated
so many times by hardware with write only registers that I should
have seen this myself.

But, now after thinking about it for a few days, I'm not sure how it
should be done.  There would seem to be two quite different, but
equally possible approaches, though neither is ideal.  One would be
for settz() to save the arg string it is called with, and for a
new function (gettz() ?) to return it.  That sounds simple enough,
but unfortunately might be something of an implementation headache.
The string can be of arbitrary length, so no static buffer in settz
to hold it would be appropriate.  That means that settz would be
required to malloc() memory to hold this string, just on the off
chance that it might be needed later (which it very rarely will be).
I really have very limited enthusiasm for making library routines
at this level get involved in storage allocation.  (Settz could
presumably just remember the pointer to the string it was passed,
and gettz could return that pointer - but this has so many potential
problems that its not worth contemplating).

The (an?) other implementation would be to define two functions,
perhaps savetz() and restoretz().  Savetz would return (in some
manner not important here) the internal state that settz has
established.  restoretz() would restablish that state as settz
would have left it.  This might be handled by having savetz
copy the state into a buffer supplied by the caller, or perhaps
it would malloc some memory and return a pointer to that.  Malloc
here is not a problem, as its only being done by the specific
request of the user, its not a hidden side effect.

Of the two schemes, I think I prefer the latter, but I would
appreciate comments from readers, either to the list if you
(and the moderator) think there will be general interest in your
comments, or in mail to me.


I think John Quarterman (our friendly moderator) answered your
query about the "implementors timezone" default possibility
for settz.  I might just add that I can't imagine how a new
implementation could conceivably make that choice - its just
there to cope with old code.  To implement this proposal,
an implementation must be able to obtain both the hosts
local time, and GMT without being told anything externally
(ie: by being handed either (char *)0 or "" resp).  If it
can do that, it can also easily choose one of those as the
default in cases where it is given an invalid argument.


> I propose an extension of the System V mechanism....  I propose
> that the standard add "extern char *tzname[]" ... and have wording
> that says that tzname[tm.tm_isdst] is the name of the relevant timezone.

Yes, this would be nice, unfortunately it can't work.  You are assuming
that there is just one non-DST timezone name, and all the others are
names of various DST types.  This just isn't true in general.
Since tm_isdst must be zero for any tm_* that is not a daylight
savings time representation, your scheme would allow only one
non-DST zone name.  A new field could be added to struct tm to
be the tzname[] index, but this would break all existing code
that wants zone names, and if we're going to do that, perhaps we
should look and see exactly when a zone name is required.

To the best of my knowledge, the only sensible use of a timezone
name is to associate with a human visible date/time representation.
Since these things aren't unique, they are useless to hold any
internal representation of a timezone.  In effect, that means
that the only time a timezone name will (should) ever be needed
is when a date/time has been converted for external output, and
the zone that will be wanted will be the zone of the time that
was just converted.

If anyone has a counter-example, I would be pleased to learn of it.

Given this assumption, it seems that all that's needed is for
localtime() to arrange that the relevant zone name is available
somehow, either in an external "char *" variable, or as the
return value of a function.

For Sys V compatability, and implementation could provide
char *tzname[2] and set both pointers to the zone name
needed?  Is anyone aware of any code this would break?

For v7 conpatability, the timezone(3) function could be made
to ignore its args, and just return the selected zone name.


> And while we're on backward compatibility, the SysV function tzset() could
> be defined as "if(timezone_not_set) settz(getenv("TZ");" to be compatible
> with the way it currently works; again, if this function is defined, its
> usage should be depreciated.

Certainly, AT&T, and anyone who wants to be compatible with current
Sys V programs should provide tzset as indicated, and should make it,
as far as possible (note "tzname" difficulties as mentioned above)
compatible with the functionality of the Sys V tzset.

However, including definitions in the standard, along with wording
like "don't use this, it shouldn't be here, and is going away"
seems ludicrous to me.


> System V also defines external variables for the current timezone and daylight
> savings rule.

I don't know about daylight savings rule, I don't remember that one,
and my Sys V manual seems to have walked away, but "timezone" is
impossible to get right.  There's no doubt that its intended usage
is that tzset() should set this variable to the local standard timezone
offset.  But this assumes that there is such a thing as a "standard
timezone offset" that applies for all times in the zone.  This just
isn't true..  Eg: a couple of years ago now, Singapore (I think)
changed its timezone so it would be the same as Malaysia.  What
value should be put in "timezone" for Singapore?  The correct answer
depends on what time is being converted - if its a time before the
switch, then it should be their old zone, for one after, it should be
the new zone.  That is, its not a constant!


Following quotes are from Mark Horton (cbosgd!mark)...

[about uses of "timezone"]
> Yes, there's an important use.  If you're generating an RFC 822 compatible
> Date: line, you need to know the local offset from GMT...

Nonsense!  This isn't a use of the Sys V "timezone" variable at all.
That's not the information it provides.  What you need for an RFC822
Date: line is the numeric offset of the time that was converted.
That's not necessarily the hosts local time zone (which is what
"timezone" is supposed to contain).  And even in cases where host local
time is what is wanted, "timezone" isn't it - as the local time converted
might have been a daylight savings time.  To turn the Sys V "timezone"
into the correct thing in that case, one would need to imbed some
nonsense like "if (tm->tm_isdst) timezone += 60;"  (or maybe -= 60,
and maybe the number is 3600, details are irrelevant.  And no, I
wouldn't really modify "timezone").  Getting rid of assumptions about
things like DST being one hour forwards is one of the major aims of
all this.

What *is* needed is a method to obtain the timezone offset that is
appropriate for a given time.  That's a different problem entirely.
An interface to provide this information might be valuable.  If
there isn't such an interface, then the offset can easily calculated
in a portable manner by applications (see my posting to mod.sources,
vol 6 issue 12 "datediffs" for an example of doing approximately this).


> One might even claim that, in a zone like Japan, asking for the time zone
> name should return "+0900" rather than "JST".  Probably not, but it's
> a thought.

This was, of course, a joke (and not even a good one).


Robert Elz    seismo!munnari!kre   [e-mail]

Volume-Number: Volume 6, Number 36

From jsq  Fri Jul 25 10:20:27 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: timezone implementation constraints
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Keywords: 1003.1 A.3
Date: 25 Jul 86 15:20:14 GMT
Draft-9: TZ
Status: R

From: hplabs!hao!vianet![e-mail] (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

From jsq  Sat Jul 26 23:35:50 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: timezone implementation constraints
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 27 Jul 86 04:35:36 GMT
Draft-9: TZ
Status: R

From: sun!gorodish![e-mail] (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

From jsq  Mon Aug 11 09:46:36 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: time_t range
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 11 Aug 86 14:46:25 GMT
Draft-9: time_t TZ
Status: R

From: [e-mail]
Date:     Thu, 7 Aug 86 10:24:40 EDT

I agree that time_t need not be able to represent times before 1970.
However, I think it's rather short-sighted to say that time_t should never
have its high-order bit set.  That restricts it to representing times
before January 2038.  "UNIX will be dead by then!" you say; well, people
have been predicting the death of Fortran and COBOL for a long time now,
and it still hasn't happened, nor does it show any sign of happening.  In
UNIX's case the fact that it's the first portable operating system is
likely to cause it to continue to exist in some form for MANY years.  Even
if UNIX itself doesn't last until 2038, it will certainly last long enough
that application programmers will find it useful to be able to store and
manipulate future time values later than 2038.  They would undoubtedly
appreciate it greatly if the system library routines supplied with UNIX
worked for those time values.

Personally I believe that time_t ought to be an unsigned long, rather than
signed, but that would probably break a lot of existing code.  Still, we
should avoid later problems by specifying that library routines that work
with time_t values should treat it as unsigned, and should work for the
entire range of possible values.  This at least makes it possible for
careful programmers to get their code right.

Most of the time-related facilities in UNIX have long been marked by
an amazing short-sightedness.  Let's not perpetuate it.

    Dan

Volume-Number: Volume 6, Number 39

From jsq  Fri Aug 29 13:51:32 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: negative time_t values
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Keywords: RFC.001, timezones
Date: 29 Aug 86 18:51:09 GMT
Draft-9: TZ.time_t
Status: R

From: elsie![e-mail]
Date: Mon, 25 Aug 86 18:35:05 EDT
Subject: negative time_t values

While it's true that no UNIX files date back to before January 1, 1970,
there *are* uses for times before that epoch:  in personnel data bases where
birth dates are recorded; in data bases recording astronomical events;
in stock market price data bases (as used by chartist fanatics); and elsewhere.
(And what of all those old 7094 executables that are being used on IBM machines
running UNIX or a cousin?  :-))

I see more use in the short run for being able to record times between
1901 and 1970 that I see for being able to record times after 2038.
And if we do make it into the twenty-first century, I imagine we'll be working
on machines with 256-bit registers where time_t will have a type that allows
it to represent times into the very distant future; if it's defined properly,
time_t variables will also be able to represent times into the very distant
past.

In summary:  I'd recommend retaining the ability for time_t variables to
represent times before 1970.
--
UNIX is an AT&T registered trademark.
Time is a Time/Life Incorporated trademark.
IBM is an IBM trademark.
--
    UUCP: ..decvax!seismo!elsie!ado   ARPA: elsie![e-mail]
    DEC, VAX, Elsie & Ado are Digital, Borden & Ampex trademarks.


Volume-Number: Volume 6, Number 41

From jsq  Wed Sep  3 22:42:17 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: negative time_t values
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 4 Sep 86 03:42:05 GMT
Draft-9: TZ.time_t
Status: R

From: sun!gorodish![e-mail] (Guy Harris)
Date: Sat, 30 Aug 86 20:39:06 PDT

> While it's true that no UNIX files date back to before January 1, 1970,
> there *are* uses for times before that epoch:

Yes, but there are other representations for such dates and times; there's
no particular need to have "time_t" objects represent dates in 4004 BCE, for
example.  Most of the time, they are represented as mixed-radix numbers,
giving year, month, day, etc., or year, day of year, etc..  The standard
arithmetic functions on dates (date1 - date2, date1 + offset, etc.) are
possible, if slightly less convenient, as are comparisons of dates.  Most of
the examples given don't currently use "time_t", as they're not done on UNIX
systems, and there's no good reason to change them and not much reason to
use "time_t" for future programs of those sorts.  ("time_t" is an especially
poor choice for astronomical event databases; many interesting such events
occurred more than 68 years before 1970....)

> I see more use in the short run for being able to record times between
> 1901 and 1970 that I see for being able to record times after 2038.

Yes, but is there a use for recording UNIX file modification times between
1901 and 1970?  Other times can be recorded in forms other than a "time_t".

> In summary:  I'd recommend retaining the ability for time_t variables to
> represent times before 1970.

It's not a case of "retaining".  The 1003.1 Trial-Use Standard says that the
result of "time" represents "the value of times in seconds *since* 00:00:00
GMT, January 1, 1970" (italics mine), and that the values of the time fields
in a "stat" structure are also times since the epoch.  All definitions of
"since" in the Webster's Third in my office indicate that it refers to times
in the future of the associated event, so March 25, 1967, 18:00:00 GMT is
not a time since the epoch and is not a value that "time" will return, nor
is it a time that will appear in a "struct stat" time field.

Assigning a meaning to negative "time_t" values may be straightforward in
that it's done by replacing "since" with "before, at, or since"; however, it
does involve changes to existing UNIX implementations to permit them to be
interpreted as local times (even with table-driven time zone conversion
routines, one has to get the tables right!).  Few, if any, existing programs
deliberately store negative values in "time_t" variables; many of those
programs are likely to want to store times more than +/- 68 years from the
epoch, so liberalizing the meaning of "time_t" isn't going to help them.
They'll have to wait for the hypothetical time in the future when "time_t"
is made a "long long int" or when all 32-bit machines have been replaced by
64-bit machines to make "time_t" useful to them.

Volume-Number: Volume 6, Number 42

From jsq  Wed Sep  3 23:00:15 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: negative time_t values
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Keywords: RFC.001
Summary: disagree with ado
In-Reply-To: <[e-mail]>
Date: 4 Sep 86 03:59:55 GMT
Draft-9: TZ.time_t
Status: R

From: hadron![e-mail] (Joseph S. D. Yao)
Date: Tue, 2 Sep 86 04:14:29 edt
Organization: Hadron, Inc., Fairfax, VA

In article <[e-mail]> you write:
>From: elsie![e-mail]
>While it's true that no UNIX files date back to before January 1, 1970,
>there *are* uses for times before that epoch:  in personnel data bases where
>birth dates are recorded; in data bases recording astronomical events;
>in stock market price data bases (as used by chartist fanatics); and elsewhere.

These should be recorded in the DATE format of your DBMS, not as a
longint!  If your DBMS has no DATE format (tsk!), it should be recorded
as three [or six] ints.  Yes, I know you'll have to compare via a
procedure instead of an op; see the (tsk!) above.

>(And what of all those old 7094 executables that are being used on IBM machines
>running UNIX or a cousin?  :-))

What of them?

>I see more use in the short run for being able to record times between
>1901 and 1970 that I see for being able to record times after 2038.

Possibly.  But I plan to be living (and making plans) well into the
2000's.  I don't want to run up against a wall.  (I already have, in
that versions of Unix today don't allow such dates, and I have -- I
don't remember why! -- tried to use them.)

In addition, you would not be "retaining" any capability -- the systems
I know tend to turn negative dates into something on the order of:
    Sat Feb  5 01:28:16 2^A06
(This is -(60*60*24): the '^A' is, yes, a control-A.)
Any date after 31 Dec 1999 up to some value >> 2^31 loses everything
after the '2' in the year:  I think the second char of the year is
being converted to a control-@, or NUL character.

(Results from 4BSD and Ultrix on VAX and 680x0 processors.  I haven't
tried this on the s5/VAX.)
--

    Joe Yao        hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}
            [e-mail] (not yet domainised)

Volume-Number: Volume 6, Number 43

From jsq  Fri Sep  5 17:46:54 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: negative time_t values
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail] (Larry Campbell)
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Keywords: RFC.001
Summary: not all unix libraries are broken
Date: 5 Sep 86 22:46:42 GMT
Draft-9: TZ.time_t
Status: R

From: [e-mail] (Larry Campbell)
Date: Fri, 5 Sep 86 01:51:09 EDT
Organization: The Boston Software Works, Inc.

>From: hadron![e-mail] (Joseph S. D. Yao)
>
>In addition, you would not be "retaining" any capability -- the systems
>I know tend to turn negative dates into something on the order of:
>    Sat Feb  5 01:28:16 2^A06
> ...
>(Results from 4BSD and Ultrix on VAX and 680x0 processors.  I haven't
>tried this on the s5/VAX.)

For what it's worth, I tried several interesting values on my VENIX 2.0
(V7-based) system.  It handles negative values "properly" (that is, it
prints reasonable dates prior to 1970);  for instance, 0xC0000000 yields
"1935 Dec 23 05:22:56".  And it also handles dates beyond 2000 correctly;
0x70000000 yields "2029 Jul 18 01:49:52".
--
Larry Campbell                             The Boston Software Works, Inc.
ARPA: [e-mail]   120 Fulton Street, Boston MA 02109
UUCP: {alliant,wjh12}!maynard!campbell     [phone]

[ Depends on what you call broken.

Another example where time values outside the currently supported
(or proposed) range would be useful:  some of us like to play with
genealogical software;  I have known ancestors back to the thirteenth
century and frequently work with data to the sixteenth century.
But time_t probably isn't the appropriate format to keep such dates,
considering Julian vs. Gregorian calendars, old and new style new years,
etc.  -mod ]

Volume-Number: Volume 6, Number 44

From news  Mon Sep 15 09:57:17 1986
From: std-unix%ut-sally.UUCP@sally (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: negative time_t values
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Keywords: RFC.001, time zones
Date: 15 Sep 86 14:57:00 GMT
Draft-9: TZ.time_t
Status: R

From: cbosgd!cbosgd.ATT.COM![e-mail] (Mark Horton)
Date: Wed, 10 Sep 86 12:40:40 edt
Organization: AT&T Bell Laboratories, Columbus

There are many uses for dates, on which you'd like to be able
to do arithmetic.  I don't see where the assumption that time_t
is only useful for file modification times got made.  We have
an application that needs to be able to store birth dates of
people living today, and of their parents.  We would like to be
able to use the same format for parents' birth dates and for
machine generated time stamps.  And we'd like to be able to
easily add or subtract 3 hours, for example, from such a quantity.

Note that all the UNIX routines to deal with dates, such as ctime,
localtime, gmtime, and asctime, deal with time_t quantities.  There
are no operations provided to manipulate a struct tm.  This means
there's a huge penalty for any application that needs to manipulate
times that might be before 1970 or after 2038.  They must implement
a set of primitives to manipulate a struct tm or other data structure
(such as an ISO format time string, which is also broken into year,
month, day, etc.)

Even if you offered us dates back to 1901, it wouldn't be enough for
our application.  We have to go back to about 1850.  But I would hope
to see some facilities added to manipulate a more general date/time
format than a time_t.  Maybe the 4.2BSD struct timeval needs to have
another field added to indicate a base year (defaulting to 1970.)

    Mark

[ There are manipulation (adding, subtracting) routines for timeval
in the 4.2BSD kernel, by the way, though they never seem to have been
brought out into a user-accessible library, even in 4.3BSD (except
for timerisset, timercmp, and timerclear in <sys/time.h>).  -mod ]

Volume-Number: Volume 6, Number 47

From news  Mon Sep 15 11:17:56 1986
From: std-unix%ut-sally.UUCP@sally (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: negative time_t values
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Keywords: RFC.001, time zones
Date: 15 Sep 86 16:17:41 GMT
Draft-9: TZ.time_t
Status: R

From: mnetor!utzoo!dciem![e-mail]  (Mark Brader)
Date: Thu, 11 Sep 86 18:37:22 edt

> Another example where time values outside the currently supported
> (or proposed) range would be useful:  some of us like to play with
> genealogical software;  I have known ancestors back to the thirteenth
> century and frequently work with data to the sixteenth century.
> But time_t probably isn't the appropriate format to keep such dates,
> considering Julian vs. Gregorian calendars, old and new style new years,

I would say that time_t WOULD be the appropriate format, for PRECISELY
those reason, if the range was available.  To say otherwise is to say
that time_t is inappropriate for the way it's normally used because of
time zones and daylight and standard time.

[ Not precisely, since the form a date is recorded in may vary according
to not only present location but national origin of the recorder or of the
person whose date it is, since there are relatively odd formats (1617/18
is a common format, being used with a date between Jan 1 and Mar 15),
since many dates are incomplete (e.g., only year is known), and since
accuracy to the hour is very rare, not to even mention minutes or seconds.

Incidentally, the Mormon Church is coordinating the development of
something called GEDCOM (GEnealogical Data COMmunications), which is
a genealogical data interchange format.  (It looks rather like a network
presentation layer to me, even resembling XDR a bit.)  They must have
produced some standard for genealogical dates.  I believe I will write
off for a copy for myself.  The address (if anyone else is interested)
is probably

    Genealogical Department
    Ancestral File Operations Unit
    50 E. North Temple St.
    Salt Lake City, UT 84150

However, I suspect that general discussions on genealogy belong in
another newsgroup, so submissions to mod.std.unix related to genealogy
should probably be kept related to date formats or other implementation
issues.  -mod ]

While I'm writing I must correct the common assertion that time_t represents
a time in the UT (GMT) system.  It doesn't.  It represents a time in seconds
from a certain epoch.  The time in time_t form at the moment, for instance, is
526,841,748.  The corresponding time in UT is 4:55:48 pm.  Granted that
the latter is derived from the former by slightly simpler arithmetic than
is my local zone time, that doesn't mean that a time_t represents a time
in UT in particular.

I don't think this is of sufficient interest to post to mod.std.unix,
but you may post any or all if you wish.

Mark Brader, utzoo!dciem!msb
    If ... it seems easier to subvert UNIX systems than most other systems,
    the impression is a false one.  The subversion techniques are the same.
    It is just that it is often easier to write, install, and use programs
    on UNIX systems than on most other systems, and that is why the UNIX
    system was designed in the first place.
                -- Frederick T. Grampp & Robert H. Morris

Volume-Number: Volume 6, Number 48