However, I can certainly see uses where converting from some other
timezone would be a nice ability to have - especially parsing rfc822
style Date: lines. But I think this is a pretty specialized usage,
there aren't that many other applications where the necessary zone
information is going to be available in just the right form.
It's not specialized at all. UNIX already provides two different timezones:
localtime and gmtime. If we're going to provide an inverse to localtime,
where does that leave the inverse to gmtime?
Most places where times are used with the zone included, the zone
is converted to its zone name form, and that is not an invertible
operation - there is no definable mapping from zone names to numeric
offsets, so the ability to make this transformation correctly isn't
going to happen all that often.
I gather you don't read ISO standards or RFC's 822 or 850.
The ISO standards have you say "+hhmm", e.g. +1030 or -0500. 822 and 850
let you say EST or PDT or whatever for the USA timezones, but recognizing
that this convention doesn't extend outside the USA, require that the
explicit zone offset be used for other zones.
What's more, in cases where I simply want to convert a local time
in struct tm format to a time_t, I am not necessarily going to
know what the zone is. Consider the use of mktime() inside date(1).
Some user types a date/time which is easy to parse into a struct tm,
from there it should be possible to use mktime() to get the time_t.
But if you have to know the zone first things aren't nearly that easy.
It certainly isn't a constant - it depends on the particular time
that the user typed.
Some applications will have a default time zone (the local one), others
will default to UT. But with a struct tm that was generated by gmtime
or localtime; we should expect that these routines filled in the
appropriate value. If we got a date string from another machine (mail,
news, network transaction) the time zone should be extracted from it.
I have a couple of misgivings about your implementation though.
I'm not sure exactly what the point of having 2 fields for hours
and minutes is - that assumes that the offset is an even number
of minutes (no odd seconds) which while likely, isn't something
I would want to bet my life upon (I would assume that the USG people
assumed it likely that there would be no minute offsets, only even
hours when doing the standard Sys III/Sys V implementation...)
So, I would suggest a single field that contains the offset in seconds
from GMT.
In principle I agree that seconds is a better way to do it. I note, however,
that minutes was good enough for ISO, and I have been unable to get any
evidence that there are places that have their timezone an offset from
UT that isn't an even minute.
Secondly, I'm not sure why you chose to have West of Greenwich being
negative. All previous uses of timezone offsets in Unix have been
the other way - West of Greenwich positive. I know that the ISO
standard defines it as West == negative, but its surely an arbitrary
choice, its trivial to negate the value anywhere an ISO form
of offset is needed, and keeping this compatability with current (old)
usages (from v6 through 4.3bsd, and pwb to Sys V) certainly seems
to be a worthwhile objective.
I'm sorry, but given a choice between a well defined ISO standard and a
egocentric UNIX implementation, I don't see any excuse for violating the
ISO standard. Upward compatibility may require that external variables
like timezone, TZ, or the ftime system call remain backwards for upward
compatibility, but we're defining a new function here. Hell, TZ and ftime
aren't even to seconds resolution, anyway.
Mark
