Date: Sun, 8 Feb 87 21:35:31 est From: mark@cbpavo.mis.oh.att.com (Mark Horton) Message-ID: <8702090235.AA06267@cbpavo.MIS.OH.ATT.COM> 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. Yes, I'm quite aware of this. But as I said, this is a fairly specialized use. Most of the world's applications don't involve parsing mail date headers, and similar. The most common application for something like mktime() is almost certainly going to be so that users can enter dates in a whole variety of applications, for all kinds of purposes. Usually in such cases, you want the user to be able to enter the least amount of information that makes sense ("Mar 1" or something) and have the program supply the rest. Supplying reasonable defaults for all the info that is needed for the initially proposed mktime() is easy - supplying a default for the zone is VERY hard. Yet, that is what your proposal required. Before calling mktime() the process would need to put something in the offset field(s) for mktime to use. Sure, if you want to invert GMT that's easy, but I submit that's also not a common case (even in the UK). Note, I'm not arguing that the ability to convert a time, and specify the zone offset is not useful, and even necessary, it just shouldn't be mandatory. However, given that there need to be two different calls to achieve these two different purposes, it seems as if it would be better to be to make the "offset" an arg to the call that needs it, rather than using the field in the struct tm. This is just a matter of taste. 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'm sure that there are applications where its useful to convert a time_t to a tm and then convert it back to a time_t again, though just now I can't think of one. Most applications for mktime() are going to be where the tm has been filled in from a time in text form, something typed by a user, parsing ctime() output from some other process, etc, and NONE of these is likely to supply useful zone information. Ctime() output may have been augmented by the zone name, but that's useless except in wierd special cases like rfc822 headers where its arbitrarily constrained by some rule like "only the US has abbreviations worth considering". 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. No, but the Sys V "extern long timezone" is. Never mind, I will accept having the offset in "east is positive" format if that's what everyone feels is best. I'm still a little concerned that it will cause bugs because of the confusion, but not concerned enough to hold out for keeping the old style. Related to other mail recently .. I think one offset is enough in the tm, to give this information, another to tell how much dst correction has been applied isn't likely to be useful. That's especially true when considered against a location that might decide to have 1 hour dst all year and 2 hours in summer, then later decide that this is a stupid situation, and just advance its zone by an hour, and have 1 hour dst in summer. Nothing in the converted times (or gmt offsets) would be altered by this rationalisation of naming (maybe the tm_isdst field), but if there was a dst offset field it would need to be altered - anything using that for anything productive would suddenly act differently, and that would seem to be a bad idea. If its not safe to use the data, then there doesn't seem to be any point having it. And yes, I also see no sensible use for tm_isdst, except that one is too entrenched now to delete. kre