Usenet 1994 October/usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso/std_unix/RFC.001

Internet Message Format | 1987-11-26 | 27KB

From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: RFC.001 Timezones
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 17 Jul 86 22:46:09 GMT
Draft-9: TZ.RFC.001

This is the first of a series of five articles about timezones.
It is posted to make public previous discussions in this area
and not to stir up the issue again.  The time is propitious because
the U.S. President has just signed a new daylight savings time law.

The other four articles of this series form RFC.001,
which was submitted to the IEEE 1003.1 Working Group in
Florence on 18 April 1986.  The set of articles is as follows:

    V6N29 RFC.001 Timezones:  this article (not part of RFC.001 proper).
    V6N30 RFC.001 Summary of mod.std.unix Volume 5 by the moderator.
    V6N31 RFC.001 Timezone Interface (reposting of V5N65) by Robert Elz.
    V6N32 RFC.001 Timezone Examples (from V5N57) by Arthur Olson.
        (just the examples from the last few pages, not the whole article).
    V6N33 RFC.001 Time Zone Proposal by jsq.

The last item has the same intent as the Elz article but is in a form which
should be usable as an actual proposal.  It may be submitted as such soon.

There was another RFC (from HP) which solved all the same problems but
by a slightly different mechanism.  Perhaps its author would like to post it?

Volume-Number: Volume 6, Number 29
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: RFC.001 Summary of mod.std.unix Volume 5.
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 17 Jul 86 22:53:24 GMT
Draft-9: TZ.RFC.001

Summary of time zone discussion (and other material) in mod.std.unix Volume 5.
The time zone discussion was in response to a request in P1003 Appendix A.3.
The numbers in parentheses like (N3) correspond to article number within
Volume 5.

The *problem* was first stated by Mark Horton (N3).
    * GMT/local time disparities exist in the real world:
    Internal system time must be GMT (N11) as used by make (N6), etc.
    Many log files are in local time, e.g., RCS, SCCS (N15).
    Users want to see dates displayed in local time (N3).
    Some parameter files are in local time, such as
        UUCP's L.sys (N5), crontab (N13), and at (N69).
    Conversions should work for dates from at least 1 Jan 1970 (N26)
        (for ls, SCCS, RCS, other logs) to near future
        (L.sys, crontab, at) (N65).
    * Network/dialup logistics:
    Synchronization of networked hosts also requires internal GMT (N17).
    Some network-related logs should perhaps be in GMT (N10).
    Users may be in different timezones than hosts (N7, N14, N13).
    Client workstations may be in different time zones than servers (N63).
    * Politics in the real world sets time zones:
    There are many standard one-hour-from GMT timezones (STs);
        some of them may have different names in different countries.
    There are many Dalight Savings Times (DSTs) related to STs,
        usually by adding one hour.
        These DSTs differ even within the same ST (N63).
        Double daylight savings time is sometimes used (N62, N58).
        Even daylight losing time is plausible (N51, N65).
    Sometimes the DST offset from ST is not integral hours (N28).
    There are local times which are not DSTs
        and also not integral hours from GMT (N19, N13).
    Offset precision of minutes is necessary (N19) but seconds not (N63).
    ST may change at any time (China switching to several zones, N62).
    DST may change at any time and with little notice (Australia, N65).
        or for brief periods (U.S. presidential elections, N27).
    Timezone names may conflict (Bering Strait Time/British Summer Time)
        or be non-alphabetic (N54, N48).

Some *deficiencies* of existing implementations (N3).
    * V7/BSD: inefficiency of system call.
    * System III/V: initialization and security (N3, N66, N63, N4, N50);
    one hour precision is not enough (N63).
    * both: DST tables wired into kernel or library, respectively.

Proposed *solutions*.
    * Early proposals by Kenneth Almquist (N24) and Bob Devine (N47)
    were very useful for discussion but flawed.
    * Interface as proposed by Robert Elz (N65):
    Three conversions sufficient:  GMT, default local, user's local (N55).
    Timezone format left to the implementation.
    Timezone in environment allowed.
    Default initialization and security provided.
    (A routine to translate timezone name to offset possibly useful (N67).)

Proposed *implementation* by Arthur Olsen (N68,N57) since posted to mod.sources.
    * Inspired Elz's interface and is sufficient for it (N65).
    * Jack Jansen's implementation would also fit Elz's interface (N65).
    * Miscellaneous implementation criteria:
    Should not be shell-specific (N49).
    Should not put timezone offset in u-area (N22, N21, N20).
    Efficiency requirements (N66):
        conversion    of present time fast for logging,
            of near past pretty fast for "ls -l",
            of distant past may be slow.
    * A particular implementation may be broad or narrow,
    depending on the intended market (N65, N63).

Far *future* considerations.
    * Machines are currently considered stationary (N60).
    * Days may not be of 24 hours (N58).
    * Announcement of info-futures list (N59).

Other topics in mod.std.unix Volume 5, with numbers of the
corresponding sections of the IEEE 1003.1 Trial Use Standard:

setuid and environment clearing (N39, N31) 3.1.2.
setuid switching (N46, N45, N44, N43) 4.2.2.
ex-directory (N12, N8)
directory umask 5.3.3, 5.6.1.
    motivation (N35, N23, N22)
    objections (N34, N33, N25)
    proposals to use .cshrc (N30, N35, N29)
    clarifications:  not per cwd (N38); process umask remains (N40)
    philosophy (N42, N37)
    solution (N41)
The IEEE 1003 Committee
    and mod.std.unix (N36, N33, N35)
    Draft 6 (N2)
    meetings:  Denver (N18); Florence (N71).
administrativia (N1, N30).
guest moderator (N71, N70).

End of summary of mod.std.unix Volume 5.

Volume-Number: Volume 6, Number 30
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: RFC.001 Timezone Interface
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 17 Jul 86 23:03:01 GMT
Draft-9: TZ.RFC.001

[ This is part of RFC.001 and is a reposting of V5N65. -mod ]

Date: 02 Mar 86 05:47:32 +1100 (Sun)
From: Robert Elz <munnari![e-mail]>
>Subject: localtime(), ctime() and timezones

It seems to me that this discussion is getting a bit overblown,
as far as P1003 is concerned, it doesn't really seem to be
as difficult or complex as some people are making out.

So, I'm going to propose something that could be inserted into
P1003 (with the obvious extra definitions that I'm going to
leave out on the assumption that everyone knows what they are,
like the definition of a "struct tm").

In some words of other, it would go like this (with hopefully
a lot of cleaning up of the typography to get rid of quotes
and things like that where I would really prefer to use italics
or bold):

Implementations shall provide the following functions:

    struct tm *gmttime(t) time_t *t;
    struct tm *localtime(t) time_t *t;
    int settz(p) char *p;
    char *asctime(tp) struct tm *tp;
    char *ctime(t) time_t *t;

gmttime: converts the time_t "*t" to a "struct tm" representing
the same time (in Universal Co-ordinated Time).  (waffle about
the returned value being in a static area, etc, goes here).

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"));".  Implementors should note that for any defined
past time (from midnight January 1, 1970 until the time the call is made)
the local time returned should be accurate (taking into account the effects
of daylight saving, if any).  For future times, the local time returned
should be as likely to be accurate as current projections of
future timezone rules and daylight saving time changes allow.

settz: enables users to specify the local time conversion to be
used by localtime.  The string is an implementation specific
representation of the timezone offset desired, with 2 special
cases..  The null pointer (t == (char *)0) will always select
the appropriate local time offset for the host executing the call.
A null string (t != (char *)0 && *t == '\0') will select
no local time transformations (making localtime() equivalent
to gmttime()).  Implementations should provide, and document,
some mechanism to allow users to select another timezone.
This mechanism is beyond the scope of the standard.  Implementors
should, if possible, allow users to define their own timezones,
and not restrict them to use one of some standard set.
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).
settz returns 0 if the timezone selected could be obtained, and
-1 otherwise.  settz can be called as many times as needed, each
call affects future calls of localtime, until another call to settz.

acstime: returns a 25 character string representing the time
specified by "*tp".  The format of the string is ... (you all know it).

ctime: is defined to be "asctime(localtime(t))".

...................

Notes: this is (about) the right level of detail for the standard.
There is no need to specify what the form of the argument to
settz() is.  This enables things like the Sys V "EST5EDT" string,
and Arthur Olson's (elsie!ado) "localtime" "Eastern" etc, to all
be used with impunity - the implementor gets to choose whatever
is appropriate to him - just provided that he can satisfy the
needs of his customers (implementors who provide no means of getting
daylight saving right in the Southern hemisphere can probably
expect not to sell many copies there - but that's their choice).

In particular - this discourages programmers from writing programs
which "know" what the local time should be - there's no reason at
all why a program should ever need to do more than select GMT,
host local time, or a user specified time zone.  (nb: while localtime
uses the TZ environment variable in cases where the program has made
no call to settz(), there's nothing to stop a program getting the
argument to settz() from anywhere it pleases, including from several
different environment variables if it chooses, and needs to operate
in several timezones, or from an external configuration file, or
wherever is appropriate).

This works for existing programs (in general) - localtime() performs
the required call to settz() the first time it is called (directly
or via ctime()).  There's no need to worry about who sets TZ, if
its not set, getenv("TZ") will return (char *)0 and settz() will
then use the appropriate local time for the host.  How settz()
gets that information is an implementation matter.  The security
problems (people faking local time for programs that expect it
to be host local time, by setting TZ before running the program)
can easily solved by causing those (comparatively few) programs
to do "settz((char *)0)" before their first call to localtime().

What's missing:  So far here there is no mention of the "timezone name".
None of the standard mechanisms is really adequate here.  The V7
(and 4.xbsd) "timezone" function is clearly inadequate (although
4.2 bsd allows users to set the environment variable TZNAME to anything
they like) since there can clearly be several possible names for the
same offset, and "timezone" has no way to discover which one is wanted.
Requiring the name to resice in the environment somewhere (Sys V) is also
inadequate (there are too many problems about making sure it is set
in all the right places).

Arthur Olson's scheme causes "localtime" to set a global variable
"tz_abbr" to the correct string name for the timezone just used.
I can't think of any cases where anything more than this is needed,
but it is less flexible then "timezone()" and it would require
programs that currently call timezone() to have to be altered.
(He also has his version of "ctime" (but not "asctime") include
the timezone in its output - I doubt if that is feasible for P1003,
too many existing programs know what every byte in the returned
string from ctime() contains.)

I solicit suggestions for what to do here - 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() - then with ado's implementation it could simply
ignore its arguments and return tz_abbr - I suspect that would
satisfy all existing uses (and the ones it doesn't are quite
likely not to work in general anyway).  Opinions?

There's also no discussion of how this relates to processes
and images.  Not because there's anything doubtful here,
but just because the necessary words take a lot of space.
(informally, "the first call to localtime" is intended to
be "the first after the program is exec'd, ignoring any
fork()'s it may have since performed, as long as there
has been no subsequent exec).  Getting this kind of thing
right is essential for a standatds document, its not essential
here.

...................

A justification for all this ...  Today, just about 2 1/2 hours ago
(it's early on a Sun morning as I write this) the daylight saving
rules changed in at least 2 Australian states (no-one really seems
very sure of what happened, or really why).  The politicians gave
us less than a month's warning that it was coming (and the month
was February, which isn't a long month...).

If there's anyone who doesn't believe that some form of dynamic
timezone setting is required, they're welcome to come to Australia
and suffer our local politicians (this isn't the first time: a
couple of years ago New South Wales decided to extend daylight
saving for a month to try and save on power bills - the amount of
notice given was about the same - at that time, at least one local
site decided to scrap running on GMT and run on localtime (ala VMS)
instead.  They're still doing that, I think, and suffering because
of it).

I'm extremely grateful that Arthur Olson decided to try an implementation,
and donate it to the community - he made the task of converting things here
much easier than it otherwise would have been.  His implementation
meets the above specs (in fact, it inspired them...), and will work
for all the contorted exampes that people have been proposing (multiple
shifts in a year, multi-hour saving, even daylight wasting).

But note - there's no need for the standard to require this
generality, market pressures will do that - all the standard
needs to do is supply a suitable interface.  Arthur Olson's
implementation proves that the above reccomendation is
implementable (munnari is running his code, in libc, right now)
and effecient enough.

[ Your last sentence gives the reason that I've encouraged
discussions of implementations in the newsgroup:  it's good
to know that a proposed standard is implementable and handles
actual cases.  But you're right, of course, that the
P1003 standard doesn't need implementation details.  -mod ]

Jack Jansen's (mcvax!jack) somewhat similar, but slightly different scheme
would probably work just as well.

Bob Devine's (hao!asgb!devine) "I don't think its needed" attitude
can also fit the standard - if he's right then he's probably going
to have a very fast localtime() which will serve him well.
If he's wrong, then he's not going to get many customers.

That's good - the more the better - that gives us users (or us system
implementors perhaps) a wide choice of methods.

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

Volume-Number: Volume 6, Number 31
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: RFC.001 Timezone Examples
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 17 Jul 86 23:06:37 GMT
Draft-9: TZ.RFC.001

[ This is part of RFC.001 and is a reposting of some examples from V5N57.
Note that the current version of Arthur Olsen's implementation
is to be found in the mod.sources archives, not in mod.std.unix.
This posting is intended merely to illustrate the variety of
possible timezones.  -mod ]

echo tzcomp.8 1>&2
cat >tzcomp.8 <<'End of tzcomp.8'
.TH TZCOMP 8
.SH NAME
tzcomp \- time zone compiler
.SH SYNOPSIS
.B tzcomp
[
.B \-d
directory ] filename ...
.SH DESCRIPTION
.I Tzcomp
reads text from the file(s) named on the command line
and creates the time zone information files specified in this input.
If a
.I filename
is
.BR ` - ',
the standard input is read.
.PP
This option is available:
.TP
.B \-d directory
Create time zone information files in the named directory rather than
in the standard directory named below.
.PP
A sharp characters (#) in the input introduces a comment which extends to
the end of the line the sharp character appears on.
Any line which is blank (after comment stripping) is ignored.
Non-blank lines are expected to be of one of three
types:  rule lines, zone lines, and link lines.
.PP
A rule line has the form
.nf
.B
.ti +.5i
.ta \w'Rule 'u +\w'MostNA 'u +\w'FROM 'u +\w'1973 'u +\w'TYPE 'u +\w'Apr 'u +\w'lastSun 'u +\w'2:00 'u +\w'SAVE 'u
.sp
Rule    NAME    FROM    TO    TYPE    IN    ON    AT    SAVE    LETTER/S
.sp
For example:
.ti +.5i
.sp
Rule    MostNA    1969    1973    -    Apr    lastSun    2:00    1:00    D
.sp
.fi
The fields that make up a rule line are:
.TP
.B NAME
Gives the (arbitrary) name of the set of rules this rule is part of.
.TP
.B FROM
Gives the first year in which the rule applies.
.TP
.B TO
Gives the last year in which the rule applies.
The word
.RB ` only '
may be used to repeat the value of the
.B
FROM
field.
.TP
.B TYPE
Gives the type of year in which the year applies.  If
.B TYPE
is
.B
"-"
then the rule is taken to apply in all years between
.B FROM
and
.B TO
inclusive.
If
.B TYPE
is something else, then the command
.B
.ti +.5i
years from to type
.br
is executed with arguments
.IR from ,
.IR to ,
and
.IR type
taken from the rule line; the rule is taken to apply only in those years
printed by the
.I years
command.

The distributed
.I years
command is a shell script that can handle year types
.B uspres
(United States presidential election years)
and
.B nonpres
(all other years);
other year types may be added by changing the script.
.TP
.B IN
Names the month in which the rule takes effect.  Month names may be
abbreviated.
.TP
.B ON
Gives the day on which the rule takes effect.
Recognized forms include:
.nf
.in +.5i
.sp
.ta \w'lastSun  'u
5    the fifth of the month
lastSun    the last Sunday in the month
lastMon    the last Monday in the month
Sun>=8    first Sunday on or after the eighth
Sun<=25    last Sunday on or before the 25th
.fi
.in -.5i
.sp
Names of days of the week may be abbreviated or spelled out in full.
Note that there must be no spaces within the
.B ON
field
(or within any other field).
.TP
.B AT
Gives the time of day at which the rule takes affect.
Recognized forms include:
.nf
.in +.5i
.sp
.ta \w'1:28:13  'u
2    time in hours
2:00    time in hours and minutes
15:00    24-hour format time (for times after noon)
1:28:14    time in hours, minutes, and seconds
.fi
.in -.5i
.sp
.TP
.B SAVE
Gives the amount of time to be added to local standard time when the rule is in
effect.  This field has the same format as the
.B AT
field.
.TP
.B LETTER/S
Gives the "variable part" (for example, the 'S' or 'D' in "EST" or "EDT")
of time zone abbreviations to be used when this rule is in effect.
If this field is
.B
"-",
the variable part is null.
.PP
A zone line has the form
.sp
.nf
.ti +.5i
.ta \w'Zone 'u +\w'Eastern 'u +\w'GMTOFF 'u +\w'MostNA 'u
Zone    NAME    GMTOFF    RULES    FORMAT
.sp
For example:
.sp
.ti +.5i
Zone    Eastern    -5:00    MostNA    E%sT
.sp
.fi
The fields that make up a zone line are:
.TP
.B NAME
The name of the time zone.
This is the name used in creating the time zone information file for the zone.
.TP
.B GMTOFF
The amount of time to add to GMT to get standard time in this zone.
This field has the same format as the
.B AT
and
.B SAVE
fields of rule lines;
begin the field with a minus sign if time must be subtracted from GMT.
.TP
.B RULES
The name of the rule(s) that apply in the time zone.
If this field contains
.B
"-"
then standard time always applies in the time zone.
.TP
.B FORMAT
The format for time zone abbreviations in this time zone.
The pairs of characters
.B
"%s"
is used to show where the "variable part" of the time zone abbreviation goes.
.PP
A link line has the form
.sp
.nf
.ti +.5i
.ta \w'Link 'u +\w'LINK-FROM 'u
Link    LINK-FROM    LINK-TO
.sp
For example:
.sp
.ti +.5i
Link    Eastern        EST5EDT
.sp
.fi
The
.B LINK-FROM
field should appear as the
.B NAME
field in some zone line;
the
.B LINK-TO
field is used as an alternate name for that zone.
.PP
Lines may appear in any order in the input.
.SH EXAMPLE
[Since a sample time zone file appears in the shell archive,
this section has been omitted.]
.SH FILES
/etc/tzdir    standard directory used for created files
.SH "SEE ALSO"
settz(3), tzfile(5)
.. @(#)tzcomp.8    1.4
End of tzcomp.8
echo tzinfo 1>&2
cat >tzinfo <<'End of tzinfo'
# @(#)tzinfo    1.5

# Rule    NAME    FROM    TO    TYPE    IN    ON    AT    SAVE    LETTER/S
Rule    MostNA    1969    1973    -    Apr    lastSun    2:00    1:00    D
Rule    MostNA    1969    1973    -    Oct    lastSun    2:00    0    S
Rule    MostNA    1974    only    -    Jan    6    2:00    1:00    D
Rule    MostNA    1974    only    -    Nov    24    2:00    0    S
Rule    MostNA    1975    only    -    Feb    23    2:00    1:00    D
Rule    MostNA    1975    only    -    Oct    26    2:00    0    S
Rule    MostNA    1976    2037    -    Apr    lastSun    2:00    1:00    D
Rule    MostNA    1976    2037    -    Oct    lastSun    2:00    0    S

# Almost surely wrong:

# Rule    NAME    FROM    TO    TYPE    IN    ON    AT    SAVE    LETTER/S
Rule    Oz-Eur    1969    1973    -    Apr    lastSun    2:00    1:00    S
Rule    Oz-Eur    1969    1973    -    Oct    lastSun    2:00    0    -
Rule    Oz-Eur    1974    only    -    Jan    6    2:00    1:00    S
Rule    Oz-Eur    1974    only    -    Nov    24    2:00    0    -
Rule    Oz-Eur    1975    only    -    Feb    23    2:00    1:00    S
Rule    Oz-Eur    1975    only    -    Oct    26    2:00    0    -
Rule    Oz-Eur    1976    2037    -    Apr    lastSun    2:00    1:00    S
Rule    Oz-Eur    1976    2037    -    Oct    lastSun    2:00    0    -

# New names

# Zone    NAME        GMTOFF    RULES    FORMAT
Zone    Atlantic    -4:00    MostNA    A%sT
Zone    Eastern        -5:00    MostNA    E%sT
Zone    Central        -6:00    MostNA    C%sT
Zone    Mountain    -7:00    MostNA    M%sT
Zone    Pacific        -8:00    MostNA    P%sT
Zone    Yukon        -9:00    MostNA    Y%sT
Zone    Hawaiian    -10:00    MostNA    H%sT
Zone    Newfoundland    -3:30    -    NST
Zone    Japan        9:00    -    JST
Zone    WET        0    Oz-Eur    WE%sT
Zone    MET        1     Oz-Eur    ME%sT
Zone    EET        2    Oz-Eur    EE%sT
Zone    AEST        10:00    Oz-Eur    AES%sT
Zone    ACST        9:30    Oz-Eur    ACS%sT
Zone    AWST        8:00    -    AWST    # No Daylight Saving here?

#
# A settz("") uses the code's built-in GMT without going to disk to get
# the information.  Still, we want things to work if somebody does a
# settz("GMT"), so. . .
#

Zone    GMT        0    -    GMT

# Old names

# Link    LINK-FROM    LINK-TO
Link    Eastern        EST5EDT
Link    Central        CST6CDT
Link    Mountain    MST7MDT
Link    Pacific        PST8PDT

# "Pacific Presidential Election Time" is being contemplated in Congress

# Rule    NAME    FROM    TO    TYPE    IN    ON    AT    SAVE    LETTER/S
Rule    Twilite    1969    1973    -    Apr    lastSun    2:00    1:00    D
Rule    Twilite    1969    1973    -    Oct    lastSun    2:00    0    S
Rule    Twilite    1974    only    -    Jan    6    2:00    1:00    D
Rule    Twilite    1974    only    -    Nov    24    2:00    0    S
Rule    Twilite    1975    only    -    Feb    23    2:00    1:00    D
Rule    Twilite    1975    only    -    Oct    26    2:00    0    S
Rule    Twilite    1976    2037    -    Apr    lastSun    2:00    1:00    D
Rule    Twilite    1976    1987    -    Oct    lastSun    2:00    0    S
Rule    Twilite    1988    2037    uspres    Oct    lastSun    2:00    1:00    PE
Rule    Twilite    1988    2037    uspres    Nov    Sun>=7    2:00    0    S
Rule    Twilite    1988    2037    nonpres    Oct    lastSun    2:00    0    S

# Zone    NAME        GMTOFF    RULES    FORMAT
Zone    New-Pacific    -8:00    Twilite    P%sT

# Next really belongs in a separate file

Link    Eastern        localtime
End of tzinfo
exit
--
    UUCP: ..decvax!seismo!elsie!ado    ARPA: elsie![e-mail]
    DEC, VAX and Elsie are Digital Equipment and Borden trademarks

Volume-Number: Volume 6, Number 32
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: RFC.001 Timezone Proposal
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 17 Jul 86 23:10:14 GMT
Draft-9: TZ.RFC.001

RFC.001 Proposal Form, 18 April 1986, submitted by John S. Quarterman.

Time Zone Proposal based on work by Robert Elz and Arthur Olsen.

Add 4.5.3 and 4.5.4 to the standard and perhaps also
document Arthur Olsen's implementation in an Appendix.

4.5.3    Set Local Time Conversion
Function:  settz()

4.5.3.1    Synopsis
    int settz(p)
    char *p;

4.5.3.2    Description
The settz() function determines the conversion from GMT
of the local times returned by localtime() and ctime().
When called with a null pointer argument (p==0), settz
shall select the appropriate local time conversion for the
location of the host machine on which the call is executed.
When called with a null string (p!=0 && *p=='\0'), settz
shall select no conversion for localtime, making localtime()
and gmtime() equivalent and ctime() and asctime(gmtime())
equivalent.  When called with a non-null string (p!=0 && *p!='\0'),
settz may set the conversion according to that string.
The format of the string and the conversions it may specify
are implementation specific.  If an implementation accepts
non-null string arguments to settz, the implementation
should allow users to define their own conversions
rather than restricting conversions to a standard set.
If settz is called with a string for which the implementation
can not find a conversion, settz shall return -1, but the
conversion it sets is implementation defined and may be one of
GMT, the executing machine's local time, or local time for
the area where the implementation was performed.

4.5.3.3    Returns
Upon successful completion, settz() returns 0, otherwise -1.

4.5.4    Get Local Time
Functions:  localtime(), ctime()

4.5.4.1    Synopsis
[ as in X3J11 ]

4.5.4.2    Description
[ as in X3J11, plus: ]
The local time conversion is specified by a call on settz().
If localtime() or ctime() is called and settz() has not been called
since the last exec(), the localtime() or ctime() call shall call
settz(getenv("TZ")) before performing the local time conversion.
The local time conversion should be accurate for all times
from the base time of the time() function up to the time
the call is made.  Future times should be converted as accurately
as possible with available political information.  Daylight savings
time should be taken into account in both cases.

4.5.4.3    Returns
[as in X3J11 ]

4.5.4.4    Errors
[as in X3J11 ]

Volume-Number: Volume 6, Number 33