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
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
participants (2)
-
Robert Elz -
seismo!cbpavo.MIS.OH.ATT.COM!mark