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.