RFC.001 Timezone Interface

[Moderator, John Quarterman]

Date: 23 Jul 86 08:38:34 +1000 (Wed)
From: Robert Elz <munnari!kre at SEISMO.CSS.GOV>

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   kre%munnari.oz at seismo.css.gov

Volume-Number: Volume 6, Number 36