Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!ut-sally!std-unix
From: std-unix@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: RFC.001 Timezone Interface
Message-ID: <5369@ut-sally.UUCP>
Date: Sat, 19-Jul-86 13:36:06 EDT
Article-I.D.: ut-sally.5369
Posted: Sat Jul 19 13:36:06 1986
Date-Received: Sun, 20-Jul-86 06:20:46 EDT
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Lines: 97
Approved: jsq@sally.UUCP
In-Reply-To: <5352@ut-sally.UUCP>

From: ll-xn!s3sun!sdcsvax!ncr-sd!greg.@topaz.UUCP
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 <5352@ut-sally.UUCP> 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    Greg@ncr-sd.UUCP or Greg@nosc.ARPA


Volume-Number: Volume 6, Number 34