[tz] Proposal for new rules

[Stephen Colebourne]

On 30 August 2013 00:29, Guy Harris <guy at alum.mit.edu> wrote:
> On Aug 29, 2013, at 3:51 PM, Stephen Colebourne <scolebourne at joda.org> wrote:
>> The Vatican and Rome may have exactly the same time-zone rules but
>> they do not have exactly the same LMT.
>
> "Do not have" or "did not have"?  Do any clocks in the Vatican or Rome (other than sundials and clocks set by quirky people) *currently* keep LMT rather than some form of standard time?  The TZ database currently does not indicate what LMT currently is for Rome or the Vatican.
> And irrelevant to the time zone database until somebody updates the "europe" file to reflect the difference in LMT prior to the adoption, in both Italy and the Vatican, of standard time.

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.

I care about LMT at the moment because it is exposed to users of the
APIs I write. IIUC, zic only really handles post-1970, but we can
handle dates into the far past (thousands of years BCE). Now, I fully
understand the relative insanity of applying much in the way of zones
back then, but applying UTC everywhere would be equally wrong, thus
LMT is currently the best I have.


> So it sounds as if what you're saying here is "do not have links between two separate IDs even if the underlying zic-compiled files would be identical, if the two IDs correspond to locations in regions with different ISO 3166 country codes", to avoid offending people who don't want their region tied together with another region via a link, even if the two regions currently have the same data in the TZ file.

Yes. The proposed rule #2 is about avoiding offence across ISO3166
boundaries, whether or not such offence is likely.

I actually think there is a good case for removing LMT from the main
tzdb, and moving it to a separate lookup file. Following this
discussion I'm increasingly of the opinion that my current use of
naked LMT is a mistake (because the LMT data has been deleted and made
inaccurate in the past, so cannot be relied on). Thus I need to use
something else for the far past, say the most commonly used standard
time between 1970 and 2010.

Stephen