[tz] User time zones

Steven Abner pheonix at zoomtown.com
Thu Dec 8 14:39:12 UTC 2011

On Dec 8, 2011, at 6:39 AM, Zefram wrote:

> In that case, firstly, you don't want to go to the Asia/Tokyo timezone
> per se.  The job isn't to guess which geographical zone applies,
> it's to guess what "JST" means.  That's not so much of an issue with
> "JST", but consider "MST": you don't really care where it's coming from
> America/Denver or America/Phoenix, it could be either and means the same
> either way.  If you get "MST" for a date in July then it's probably
> America/Phoenix, and you'd go quite wrong if you were to interpret
> it as America/Denver and use the offset that Denver uses in July.
> (Denver uses the abbreviation "MDT" in July.)

In agreement.
The file list submitted was not to look up Toyko but to define JST for
quick and simple access. And UT could be done and should also be handled,
or use of %z where it's an offset. I don't think there is any bug or ever
an incorrect use of %z. It is also the right of any programmer or application
designer to simply not convert and crash the app if thats what they decide.
Not trying to dictate the terms of use of time nor time zone information!

For MST, let's first state that yes there are 8 zones that have conflicts.
In the case of MST, there is no conflict. If let's say Denver in July did
output a timestamp string of 12:00 MST, then it is a sure thing that
the computer output the correct conversion to MST, or if it didn't, a sure thing
that the use of strftime() and/or mktime() has a bug in that system. Again don't
care where it originates, just assume that the computer can output a
string for that locale or any locale. By looking up what zone the abbreviation stands
for, a conversion to any zone, locale, UTC offset is easily handled. Let's
even go one step further, Denver in July output the 12:00 MST, convert it for
use in Denver. mktime() is required to handle this and will output 1:00 MDT,
if that was the requested format, but regardless of output, the broken-down time
structure will contain the wall time information for Denver.
Let's try a past event for America/North_Dakota/Beulah, currently in Central. What if
the computer output July 4, 8PM 1976 MDT or even July 4, 7PM 1976 MST and we are
asked to interpret for anywhere. Really don't care where it came from, just that from the
look up MST = -7 and MDT = -6 for the time asked. Very easily retrieved from the Link to
MST7MDT. I now can even convert to Mars Time if that was in the database. Even
the use of a static locale like Phoenix, if a computer can output the time correctly, conversion
using the link to MST7MDT to any other locale or zone can be done. I am still looking for
exceptions, outside the 8 zones of conflict. And yes, I could have missed some! Clear
example is my incorrect knowledge of GMT.

As for an LMT case, sorry I only did 1970 and up, and have no information. The
tz database mentions several times that it was more focused in this region of the
time line. The file was more concerned with trying to go from present to future events.
Some abbreviations are listed in the look up even though not in use today, and they
had no conflict, if memory serves.

Thanks loads for all responses!

More information about the tz mailing list