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! Steve