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