[tz] Proposal for new rules

[Guy Harris]

On Aug 30, 2013, at 2:38 AM, Stephen Colebourne <scolebourne at joda.org> wrote:

> On 30 August 2013 09:59, Guy Harris <guy at alum.mit.edu> wrote:
>> On Aug 30, 2013, at 1:15 AM, Stephen Colebourne <scolebourne at joda.org> wrote:
>>> Yep. The difference in LMT is something that isn't important for Rome
>>> vs Vatican as they are the same city. But Rome vs San Marino? Also
>>> Atikokan vs Panama.
>> Rome vs. Florence?  Rome vs. Naples?  Rome vs. Milan?  Rome vs. Turin? etc.
> 
> Not time-zone IDs, but I acknowledge with the sentiment.

The sentiment is "if we're going to care about LMT, we're going to need a bigger boat^W^W^Wa lot more TZIDs, so do we ("we" as in "the time zone database") *really* want to care about LMT?"  I personally think the answer is a very strong "no", and that people who have attempted to use the tzdb for pre-standardized-time times have made a very big mistake, and people proposing to use the tzdb for pre-standardized-time times are making a very big mistake.

> Yep, LMT is clearly dodgy, but its the best we have. The core problem
> is what does the tzdb say that the offset was for times before the
> earliest zone.

I would vote for "return an error".  What should it say, in systems with a time_t big enough to encompass times that far back, for times before the formation of the solar system?

> In reality, we know that people didn't really use
> clocks and just used local sun time. LMT is one encoding of that.

Yes, but tzdb time zones don't necessarily have *an* LMT value for a particular "proleptic UTC" value; the LMT value may differ depending on where you are.

If somebody wants a mechanism to convert to local time for arbitrary time values (well, "arbitrary" limited to "during the period of human history when time was kept in a form where it makes sense"), that mechanism will need to take a longitude and latitude value as an argument, attempt to look that value up to find a tzdb zone ID and check what the tzdb says and, if it says "that tzdb zone didn't exist back then, they were using local time", convert to local time algorithmically and, if there are locations where simply assuming local time is based on the angular distance from the prime meridian is wrong, search some *other* database, developed and maintained by those who care about pre-standard-time local time values, for the appropriate time offset.

> Note that saying the tzdb starts at 1970 doesn't solve the problem. In
> both cases, users like me still need to have an offset for a zoneID in
> the far past.

If "the far past" refers to a time before the establishment of standard time, do you need an offset for a time zone of some sort, or do you need an offset for a *location*?