[tz] What is LMTZ?

[Guy Harris]

On Sep 19, 2013, at 2:45 AM, Lester Caine <lester at lsces.co.uk> 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?

> This is just part of the history that AT SOME POINT may want to be recorded. I know that some people could not care less and that perhaps is why we need to split completely from the TZ database?

I very strongly believe that information about the history of the adoption of 24-hour clocks does not belong in the TZ database, as that's orthogonal to the adoption of standard time; it could be maintained in a completely separate database used by code that displays times with a 12-hour or 24-hour clock depending on, for each time displayed, the convention in effect at that time (rather than just using the current convention).  That code could, for example, use localtime() (which might use the tzdb) to convert a time_t to year/month/day/hour/minute/second, and then choose whether to display the hour as is or to do

	if (hour > 12)
		display hour-12 with "PM"
	else
		display hour with "AM"

based on that other database.

> History is important and recording the history of time needs a home

I'm unconvinced that it needs a single home, or that, even if it does, the tzdb is the right home.

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

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