[tz] What is LMTZ?
guy at alum.mit.edu
Thu Sep 19 08:35:18 UTC 2013
On Sep 19, 2013, at 1:10 AM, Lester Caine <lester at lsces.co.uk> wrote:
> Guy Harris wrote:
>>> At some point in the future we may also need a 'clock' but I suspect that will not be so well documented?
>> If by "need a 'clock' but I suspect that will not be so well documented" you mean that the changes occur at a particular time on a particular date, whether the particular time is well documented or not, Zone lines already handle that; see, for example, the Zone lines for America/New_York:
> Sorry - in my mind 'date' is a timestamp all the time - and 1830's is a date with a 10 year time span ... genealogical standard terminaology.
> By 'clock' I meant the way time is calculated during the day ... when did '24 hour days' come in ;)
By "24 hour days" do you mean "24 hour clock", as in "one hour past noon is 13:00:00 (or 13h 00m 00s or...) rather than 1:00:00 PM", or do you mean something else?
If you mean "24 hour clock", the tzdb does not keep track of representational issues such as "12 hour clock vs. 24 hour clock"; are you suggesting that it should perhaps do so?
> All I am trying to do is provide a way forward so we can document and include pre-1972 ( and I'm going to stick with that date as a reference ) so that the 'condensed' database can exist with the full historic one.
> I'm trying to be constructive here ... the historic database will have 10's of thousands of locations, but at some 'timestamp' they will all switch to Paul's reduced timezone set. I think that there will be another set of TIMEZONES which have complex rules between 1916 and 1972 and prior to that TIMEGROUPS with a simple time offset?
I don't think there will be anything other than tzids, whether a given tzid refers to a region that doesn't have DST/summer time/whatever or to a region that does, so I see no point to saying the former refers to a "timegroup" and the latter refers to a "timezone".
If we decide to have separate tzids for all sets of locations that adopted standard time at a given date/time, then the "historic" database may well have thousands of tzids, and there will be a way of winnowing the database down to merge tzids that didn't differ before whatever date is chosen as the reference point. I presume that if a bunch of tzids were merged into one as part of the winnowing process, one of those tzids would be kept and the others discarded in the winnowed version of the database.
More information about the tz