On 30 August 2013 00:29, Guy Harris <guy@alum.mit.edu> wrote:
On Aug 29, 2013, at 3:51 PM, Stephen Colebourne <scolebourne@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