[tz] What is LMTZ?

Lester Caine lester at lsces.co.uk
Thu Sep 19 23:07:04 UTC 2013

Guy Harris wrote:
>> This was just a comment that once one moves back into 'pre-clock' time then there may well be information on how time is marked.
> "Marked" in what sense?  You still haven't indicated whether you're referring to 12-hour vs. 24-hour clocks.  Are you, or are you referring to something else?
I was simply referring to the fact that how time was measured differs vastly ... 
and at some point it may be necessary to handle that, including your example.

>> ... even the changes to calendars fit into this history.
> I don't think changes to calendars before the adoption of standard time (as was the case for the adoption of the Gregorian calendar in Western countries) belong in the tzdb.  *Perhaps* the changes from the Julian to the Gregorian calendar *after* the adoption of standard time belong in the tzdb, if there are any, should be recorded in the tzdb, if a goal is to have APIs such as localtime() return correct year/month/day dates for times during the period after the adoption of standard time but before the adoption of the Gregorian calendar.
> I think other calendars should be handled by other databases.
This is purely a mater of how far back the time related material is taken.

>> Again this is just nit picking when I'm just trying to create a path forward.
> I'm unconvinced that the path forward requires distinguishing between locations with complex rules and those that don't.
This was PURELY an attempt to distinguish between Paul's very limited set of 
timezones, and the reality of historic records.

At the end of the day we still have no statement on how historic data will be 
handled. Personally I'm less interested in the straight jacket created by the 
'c' code and more interested in the pure data as that is what I will work with 
myself, but I'm holding back until there is some plan in place to at least allow 
my pending patches can be handled ... I have a first cut on an import routine to 
SQL, and I have a fairly comprehensive table of county and smaller locations 
ready to integrate into the front end.

The data has a place on it's own and does not need to be bundled with the code!

Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

More information about the tz mailing list