On Jul 19, 2015, at 4:24 AM, Lester Caine <lester@lsces.co.uk> wrote:
On 19/07/15 01:54, Howard Hinnant wrote:
Europe/Amsterdam Initially: +00:19:32 standard LMT 1834-12-31T23:40:28Z +00:19:32 standard AMT 1916-04-30T23:40:28Z +01:19:32 daylight NST
Howard ... Historic material in TZ is still something of a Cinderella and the fact that sections of it simply become ignored because of the 1970 limit is irritating. The problem I have with the above 'rule set' is that until there was a common time agreed in 1834, there was not a previous fixed time for the area over which THAT agreement was made. The LMT tag does at least say that this time is specific to a point and that other adjacent towns MAY have different offsets. That the software needs something to work with is a given, but just as using TZ without the back file produces incorrect results prior to 1970 so do assumptions like these. The current demo tzdist claims to be 'unabridged', but in reality it is only REALLY valid post 1970 and so should flag that limitation. Paul is totally correct that we will never be able to produce a perfectly correct historic rules set for the world, but we do know when the limited set of data we are using started and all I am asking is that prior to authenticated material, LMT is observed as just that Local Mean Time as defined by the actual location, and an indication that some other mechanism maybe needed to calculate local time ... in the UK while it only applied for a short period of time, towns had their own local time and that is something that we may well be able to provide via tzdist while not encumbering TZ with the problems of validating that data. tzdist needs a geographic lookup system so that anyone can use to confirm their local timezone, something which geonames currently provides with a reasonable accuracy, but which is also by no means complete.
Thanks Lester. I understand and agree with everything you’ve said. Please understand that the validation effort is not about historical accuracy. It is about accurately retrieving and representing all of the data in the database. For example I also have: America/Cambridge_Bay Initially: +00:00:00 standard zzz 1920-01-01T00:00:00Z -07:00:00 standard MST 1942-02-09T09:00:00Z -06:00:00 daylight MWT … And I assert that this is a correct representation of the contents of the database. # aka Iqaluktuuttiaq Zone America/Cambridge_Bay 0 - zzz 1920 # trading post est.? -7:00 NT_YK M%sT 1999 Oct 31 2:00 But I am not under the impression that the abbreviation zzz was actually used in Cambridge Bay prior to 1920. Howard