I think things are getting way too complicated.
All P1003 needs (and all it should have) is a spec of
the interface that programs should have to time conversions.
And that ought to be the minimally sufficient set, not
everything that might be useful to someone, someday.
nb: this is not a reference to the "nl" procedures,
some kind of standard for that is clearly needed, or
posix will be tied to English (or what passes for English
in the US) forever.
What I am referring to is the file formats, etc, which
clearly don't need to be in any standard. What's more,
there should not even be an implication that there is a
file with this kind of information in it somewhere.
That's none of the interface's business, its an implementation
issue. On a host with good shared libraries, continuing
to compile the needed information into libc.a is a perfectly
reasonable strategy. Another would be to make a RPC call
to some server to obtain the information. P1003 has no
business outlawing any of that.
Furthermore, there is NO need for P1003 to contain everything
that's in Sys V. Not even AT&T believe that. Unless some
detail of Sys V is needed for the interface, then it should
not be there (this does not make P1003 incompatible with
Sys V, it just makes Sys V a superset, offering more than
P1003 requires). In this area Sys V's "timezone" and "daylight"
variables fall. They're next to useless, a static variable
in the Sys V sense cannot possibly contain useful information.
if they were allowed to change on each call to localtime,
to reflect the results of that call they might be useful,
but without that they're useless. I've never yet seen an
application with any excuse for using "daylight". The information
purported to be supplied in "timezone" does have its uses, but
the static variable can't contain that.
What do you think should be in "timezone" in South Australia,
where the standard zone is currently 9:30 ahead of GMT, but
which is going to change to 10:00 ahead of GMT on Mar 15 (I think)
next year? Should "timezone" be -36000 or -34200? Remember
that there will be application programs running at the instant
this switch is made (02:00 standard time, on that morning),
so any solution that involves changing the value of timezone
(a variable that isn't altered after its set by tzset()) can't
be correct. For "timezone" in the Sys V sense to be meaningful
at all, one of those two numbers (or perhaps some other) must
be chosen, and retained forever.
The v7 (inherited by bsd) "timezone()" function is a joke. It
can't even come close to doing what it claims. It has to go.
Incidentally, all the "bsd" columns here should be labelled "v7".
Bsd has made no changes to any of this, at all, ever. All that
ever changed in this area was some of the implementation details.
Also, there's no good reason for the standard to constrain the
syntax of the TZ environment variable in any way at all. If
some implementation finds that it can extract useful information
from the letters, digits, colons, etc, found in the value of
that variable, then fine. That is perfectly consistent with
an unconstrained format.
But, as soon as you introduce any unnecessary rules, things
start breaking down. As an example, last year, the TZ values
(in the standard Sys V sense) for NSW and Victoria (in Australia)
would have been identical. Both EST-10EST. (That is, both NSW
and Vic have "EST" as their timezone abbreviation in standard
time (Eastern Standard Time, as in the US), they're both
10 hours ahead of GMT, they both have daylight saving, and both
use EST as the abbreviation for the zone name when daylight
saving is used (Eastern Summer Time). But last year (for a
week) their daylight saving rules were different. The Sys V
format simply cannot cope with this kind of thing. (I think they
were different last October, if not then, they were in 1982 for
3 weeks in March).
The unconstrained form can handle this. Easily.
So, please, in any submissions to P1003 (on this point, and
any others) please emphasise simplicity. Anything that's
not demonstrably both essential, and workable, should be
omitted.
What MUST be there is some way for a program to get access
to localtime in the absense of a TZ variable. There are
security issues here, TZ is a user alterable variable, and
cannot be depended upon. This is the one thing that is
going to have to be added to Sys V. Add that, and current
Sys V should be P1003 compliant (ignoring language issues
for now). BSD is going to need more changes, but that's
not a problem, changing BSD is easy...
Personally, I don't much like the idea of doing that by
having the TZ variable changed by the application. That
would be workable, certainly (assuming that there was some
guaranteed value it could be set to to obtain local time)
but it seems more complex than is needed, and somehow just
not nearly as clean as settz((char *)0) in ado's current code.
Also, given that this is absolutely essential (and this
is THE defect in the Sys V current localtime interface
incidentally - that it has one set of daylight saving rules
compiled in is a mere implementation foible -- oh yes, the
"only hours" in the TZ variable is another defect) its
a good idea to make the default be that if there's no TZ
variable, then localtime is obtained. That means that users
who only want localtime anyway need one less environment
variable slowing down all their processes - the environment
should be used for user configuration, not system configuration.
I'm not much thrilled with tzname[2] either. To be truly
Sys V compat, that also needs to be statically set at the
tzset() - a Sys V process can now grab pointers to the
strings in tzname after tzset() and use those forever
after.
There's no way to be compatible with that, and at the same
time handle a location with more than 2 zone names. Again,
South Australia next year, it will have CST, EST and EST
all in the same year. (That two of these are the same is a
coincidence, assume for now that Australia used the US naming
convention, then the names would be CDT EST and EDT).
I gather that the current idea is to make tzname[] be a
placeholder for a result of localtime(), changing after
each call. I'm not sure what the "other" size of tzname[]
is supposed to contain though. Ie: if I reference
tzname[!tp->tm_isdst]
what do I get? Is it always defined? How? Looks
impossible to me (that is, to be defined to something
sensible). This looks to be another area where the desire
for Sys V compatibility is going wild. If its *wrong*
in Sys V than POSIX is the chance to fix it. Possibly
the last chance, forever. Perpetuating an error just
for some compatibility seems like a bad idea.
A better idea might be to add a "char *tm_zone" to "struct tm"
and shove the zone name in there. That at least makes it
quite clear that the zone name is a property of the specific
time, and that a zone name without an associated time is
a meaningless concept.
Yes, I know this is going to break some programs, and that's
a pity, but I think its necessary.
Robert Elz seismo!munnari!kre
ps: I have added a cc to John Quarterman, who I guess is
as close as anyone to being my representative on P1003,
given that I'm a usenix member... John, this is in response
to some discussions over the HP proposals and other replated
issues. elsie!ado can fill you in on what's been going on I think.
There's a mailing list at elsie for tz discussions.
