[tz] What is LMTZ?

[Guy Harris]

On Sep 19, 2013, at 4:07 PM, Lester Caine <lester at lsces.co.uk> wrote:

> 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?
> http://www.time-for-time.com/clocks.htm
> 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.

It may be necessary for some software to handle that.

I *REALLY* don't see most code that uses the tzdb, or that uses APIs that use the tzdb, needing to care about pre-standardized-time clocks except to indicate the date and time when standardized time was adopted, and don't think the tzdb needs to handle that.  I think that belongs elsewhere.

And, again, I also don't think my example needs to be handled by the tzdb.

Does anybody else believe the tzdb should handle the history of 12-hour vs. 24-hour clocks or of pre-standardized-time timekeeping other than recording when standardized time was adopted?  If not, I don't see any point in further discussion of those topics on the tz list.

>>> ... 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.

I don't think the time related material in the tzdb should go back before the establishment of standard time, for some meaning of "establishment", whether it means "adoption of standard time nationwide as civil time" or something looser.

And, at this point, as per Brian Inglis' comment, the tz code shouldn't worry about the Julian calendar, and should leave it up to other code to handle that, so that I think *all* other calendars should be handled by other databases.

If somebody wants to establish a Big Database of all changes in time and date reckoning, not just establishment of standard time and rules for changes from standard time, I have no problem with them doing so; I just don't think the tzdb should be that database, even if whoever establishes that database chooses to use the tzdb as part of their database (thus becoming a user of the database).

Does anybody else believe that the tzdb should handle non-Gregorian calendars?  If not, I don't see any point in further discussion of that topic on the tz list.

> At the end of the day we still have no statement on how historic data will be handled.

Do we have a statement as to which historic data, other than the date and time of the establishment of standard time, and changes to regions' standard time and "daylight savings"/"summer time"/whatever rules, should be handled by the tzdb *at all*?  I think we need that first, so we don't spend any time and energy discussing how to handle items that we're not going to handle.

I propose

	1) *not* including information about non-Gregorian calendars;

	2) *not* including information about whether time is presented with a 12-hour or 24-hour clock;

	3) for time prior to the establishment of standardized time, including *only* information about the date and time of its establishment;

and personally like Alan Barrett's statement:

	In the long term, think that the tz project should attempt to provide as much high-quality data as is reasonably feasible, and that users of the tz data should have the ability to "winnow" and install only a subset of the data.  Here, users of the tz data includes OS vendors, appliance vendors, other software projects, software packagers, system administrators, and end users.

so that the tzdb can have historical data about standardized time *but* should offer tools to allow users, in his sense, to discard historical data if it imposes what those users deem significant costs in excess of what they deem the benefits.