From: Paul Eggert
It is not always true that the _last_ LMT entry is correct in the sense of true solar LMT.
That is because "LMT" (like all such abbreviations) is ambiguous.
It would have been nice if the tz database had unambiguous information. I don't like XML (too much overhead, interpreting data means more programming, other factors), but in an XMLized database one could inspect tags that unambiguously define data as such and such. The results of the current discussion could be used in a far future if and when the tz database gets converted. A similar type of difficulty was discussed previously (around 2004-05-17). For instance, # Korea (North and South) ... Rule ROK 1987 1988 - Oct Sun<=14 0:00 0 S Zone Asia/Seoul 8:27:52 - LMT 1890 ... 9:00 ROK K%sT This posed no problem for the tz programs, so nothing was changed. On the other hand, if you convert the database (semi-)manually, you can only find out by meditating deep and hard that South Korea currently does not observe DST, although the Zone information says Rule ROK is in effect. Checking all this is a lot of work for all the 200+ entries, which as I have experienced, leads easily to errors.
From: David Keegel
If you were trying to get a table/database of city->LMT values for the present day, I doubt that the tz database would be a good source for that. For a start it only includes a limited set of cities
True. NGA's Geonet name server is a better source of location data (lat/lon) for millions of places. For the USA: GNIS/USGS. [The download pages: for USA & Antarctica places: <http://geonames.usgs.gov/stategaz/index.html> and for other places: <http://earth-info.nga.mil/gns/html/cntry_files.html> Don't download the 1 in all file, your word processor may choke to death!] But I did hope it were possible to extract LMT information _quickly_ from the tz database, just to get a rough idea of the discrepancy between solar time and zone time. Oscar van Vlijmen 2005-03-23