On Dec 5, 2017, at 1:31 AM, Lester Caine <lester@lsces.co.uk> wrote:
The main problem that everybody seems to be skirting around is that the tz database has NO interest in exactly where someone is located
It's obviously not the tzdb's job to determine their location, so presumably you mean "the tz database has NO interest in providing information to determine, for a given longitude and latitude, the tzdb region containing that longitude and latitude".
Even tzdist which was the latest attempt to plug a major distribution hole has no remit on supplying the correct data for a particular location!
I.e., they don't offer, for example, a service where you send it a longitude/latitude pair and it returns data for the tzdb region containing that location.
Some other data source is really needed to serve up the CURRENT set of rules for a location, and that is probably only currently possible using geonames.org which uses the current timezone_id and it's own simplified timeZone.txt table! What is missing is any historic (or ongoing) changes to that information, such as a location that was using one tz rule set but moved to another.
That would happen only if the tzdb region containing that location were to split, with the location being in the newly-created tzdb region (rather than remaining in the old region). In that case, I'm not sure why the tzdb region it was in before the split is relevant; before the split, the old region and the new region have the same rules, as they weren't yet separate regions, and after the split, the rules of the old region aren't relevant to the location.
In addition any pre-1970 material can not be identified.
That's because, as has been noted in the past, having separate tzdb regions for locations that used different rules prior to 1970 but that didn't use different rules in 1970 or afterwards isn't a high priority for the tzdb. That's a separate issue unrelated to the "mapping locations to the tzdb region in which they're located" issue.
tzdist has the remit and tools to fill one of the holes that tz on it's own can not and that is historic changes TO the rule sets.
If you're thinking of https://tools.ietf.org/html/rfc7808#section-3.10 that doesn't seem to provide anything that access to a complete archive of tzdb releases would. And that's an issue separate from the "mapping a location to a tzdb region" issue.
The whole point of tzdist was to sort current day problems, so if a mobile device with a stored calendar lands in a new location where there has been an 'unscheduled' change of tz rules that change CAN be propagated quickly without needing a full tz update but that will only work if someone is actually running the primary tzdist source. Moving forward, that primary tzdist source needs to maintain a full historic record prior to 1970
...assuming they wish to provide services for people processing pre-1970 local times. Perhaps they might not wish to, disappointing though that may be for those who want to process pre-1970 local times.
Merging geonames.org with openstreetmap.org one gets graphic displays of the area that timezones CURRENTLY cover, but one can not establish if the same offsets applied back in the 1960's when DST local times are well documented. And both databases throw away the historic data to those mappings along with a whole load of other historic material. While the vast majority of users probably could not care less, the annoyance here is that the material existed so it's not as if we are asking for extra work, just a mechanism that remembers that say in 2014 the Crimea moved from one set of tz rules to another.
...and what the tzdb did in response was to add some additional lines to the entry for the *existing* entry for the Europe/Simferopol tzdb region. I don't know whether any tzdb regions changed their boundaries; if not, then, from the point of view of the tzdb, no location changed which tzdb region it was in, the *existing* rules for a tzdb region changed by adding new transitions. That change isn't a correction to historical tzdb entries, of course, it's a consequence of the annexation of Crimea by the Russian Federation, so presumably by "it's not as if we are asking for extra work, just a mechanism that remembers that say in 2014 the Crimea moved from one set of tz rules to another", you mean "a mechanism that remembers that new entries were added to the Europe/Simferopol rules in 2014 can also be used to remember that Southeast Nowheresville's UTC offset in 1905 was corrected from 1:30 to 1:47". BTW, if there's any mechanism in tzdist to request particular versions of the tzdb, or to enumerate all of the versions that have ever existed, I'm not seeing it anywhere in RFC 7808, so either I missed it or it was added subsequently.