On 30 August 2013 21:10, Guy Harris <guy@alum.mit.edu> wrote:
If we're obliged to leave them in the tzdb for backwards compatibility purposes, we should:
accompany them with a disclaimer that they're not actually meaningful, for all the reasons discussed here (not all locations within a time zone necessarily had the same LMT value before the establishment of the zone; different people *in the same city* might have had clocks different from each other by significant amounts; etc.), explicitly stating that supporting conversion of times prior to the establishment of a standard time zone in a locale is out of scope for the tzdb;
+1
freeze them and devote no effort to updating them;
-1. So long as we have them, there should be a best efforts attempt to maintain them. Realistically, that only means that any new zone should have an appropriate LMT set. No more.
not create any new tzdb zones if the only reason for the new zone is "before standard time was established, these two locations had different LMT".
+1 (just to note that Rome vs Vatican was to fulfil the "full history in an ISO code" requirement I proposed, not to create unecessary LMTs)
Historical rules *subsequent to* time zone establishment, however, are arguably worth keeping and perhaps even updating, albeit perhaps with a disclaimer saying we can't guarantee historical accuracy and/or that they are subject to change due to additional historical information being found.
+1. This is the far more important issue. FWIW, I've started the process of removing LMT from Java JSR-310. Unfortunately, the option of throwing an error for far past values (back to the age of the universe) is not an option. I do understand the weirdness of these far past times, but in the context of the API it is simply not acceptable to have date-times in the 1700s for example without any notion of offset from GMT. https://github.com/ThreeTen/threeten/issues/332 Stephen