Subject: [Tzdist-bis] draft-tzdist-geolocate

From: Daniel Migault <[email-masked]>
Date: Fri, 19 Oct 2018 07:08:33 -0400

Hi,

I think the draft is pretty baked, however, I have a few comments:
* It seems that the association between a time zone name and a location may
change over time. It seems that the current draft assumes the date is the
current time. I am wondering if we are willing to introduce a date
parameter (default to current) or not in the current extension. If we don't
I believe we should position the current extension. In other will we have
to design a new extension from scratch or could we re-use this extension.

* Different location may also be associated to the same time zone, but
considering different time change. I believe the draft may document this as
well. Will we have always different time zone name in that case ?

Yours,
Daniel

---

From: Paul Eggert <[email-masked]>
Date: Fri, 19 Oct 2018 10:21:48 -0700

On 10/19/18 4:08 AM, Daniel Migault wrote:
> * It seems that the association between a time zone name and a 
> location may change over time..

Although this is true it's not clear to me what problem is being worried 
about here.

It's not uncommon for time zones to split, because part of the zone does 
one thing and part does another. For example, in tzdb 2017a 
America/Santiago split into two regions; the main one is still called 
America/Santiago and the less-populated one is called 
America/Punta_Arenas. A geolocation query today should return one of 
these two regions or the other; and this result will work even for older 
timestamps. A geolocation query that was conducted in 2016 would have 
returned America/Santiago even for the area that is now 
America/Punta_Arenas. However, once we know today's results we don't 
need the 2016 results, because today's results are more accurate (they 
are based on more information, that we've learned since 2016), so it's 
not clear why one would want to ask for the 2016 results.

> It seems that the current draft assumes the date is the current time. 
> I am wondering if we are willing to introduce a date parameter 
> (default to current) or not in the current extension. If we don't I 
> believe we should position the current extension. In other will we 
> have to design a new extension from scratch or could we re-use this 
> extension.

Sorry, I don't understand the proposal, or how it would help in the use 
case I mentioned above. If the goal is some sort of metaquery "What did 
the database look like two years ago?" I think that's out of scope for 
this spec. If the goal is something else, I'm not sure what it is.

> considering different time change. I believe the draft may document 
> this as well. Will we have always different time zone name in that case ?

Could you give a specific example of the problem you're thinking of? I'm 
not understanding the issue.

PS. There is one problem the spec should address, but doesn't. In some 
places there is no consensus on what the time is. A good example is 
Ürümqi, China, where the official time is either UTC -08 or UTC -06 (it 
depends on which official you're talking to). A request with geolocation 
Ürümqi should return two possibilities, Asia/Shanghai and Asia/Urumqi; 
Han prefer the former and Uighurs prefer the latter, so if a UI knows 
the preference it could presumably list that one first. The spec should 
talk about this problem and give Ürümqi as an example.

---

From: Lester Caine <[email-masked]>
Date: Fri, 19 Oct 2018 19:25:15 +0100

> not clear why one would want to ask for the 2016 results.

In effect this is the same problem as we have with trying to use data 
that was normalized with older versions of the TZ rules for a timezone. 
geonames has no provision to version the data being returned so if one 
has recorded 'America/Santiago' in historic data and one does the same 
search today and gets 'America/Punta_Arenas' then making comparisons 
more difficult. Just as if the data normalized with the 2016 rules may 
no longer match the changes introduced in 2017. Going forward, if a 
result returned today is modified for some reason next year. Having SOME 
way to enquire if a result is now different to that returned the last 
time the lookup was done is essential for data consistency as is being 
able to look up the 'America/Santiago' rule set used pre-2017 to 
un-normalize the data prior to renormalizing as 'America/Punta_Arenas' 
... simply assuming that the 'America/Punta_Arenas' data is correct for 
the older normalized data is a lottery. And given that many areas seem 
to be discussing moving between adjacent rule sets I doubt that TZ will 
want to create new rule sets for each new area created every time? 
Certainly borders are moving all the time these days even when the 
overlying timezone is not changing? SO there may well be a history of 
changes of timezone for locations not currently covered by a TZ rule set?

-- 
Lester Caine - G8HFL
-----------------------------
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

---

From: Tim Parenti <[email-masked]>
Date: Sun, 21 Oct 2018 00:23:00 -0400

On Fri, 19 Oct 2018 at 13:21, Paul Eggert <[email-masked]> wrote:

> A geolocation query that was conducted in 2016 would have

I think one major intended use of this spec is to assist in calendaring.
Suppose, in 2015, a user created an event far in the past (c. 1940) and
geolocated it to the Magallanes region of Chile.  At the time, that would
have been tagged with a TZ of America/Santiago, and perhaps cached locally
as such and/or converted to UTC accordingly.  (Existing standards are
fairly flexible for how calendaring applications can handle this upon event
creation.)  Later, we created America/Punta_Arenas to handle a modern zone
split, but perhaps (hypothetically) we were to discover that Punta Arenas
time also differed from Santiago time briefly in the 1940s.  (This is a
plausible sort of change which happens fairly often in tzdata.)  Surely, if
the event was originally specified as Magallanes local time, and had been
normalized to UTC at creation, that normalization would now retroactively
be incorrect.  Or, if we had kept the event defined in local time, but had
strongly cached the TZ as America/Santiago, the conversion *to* UTC would
be off instead.

Whether this particular case is too contrived is one thing (arguably it
is), but the expected behavior re: client caching/normalization, etc. — as
zones do in fact split — will need to be addressed.  As should already be
known for last-minute timezone definition adjustments in modern calendaring
(but I suspect is largely ignored instead), the only truly "100% correct"
solution is to flag the potential discrepancy and ask the user what to do…
but on a shared object (calendar event) being interpreted by multiple
different clients with different definitions, who exactly is "the user",
and is it worth defining the set of reasonable options that should be
presented to them?

> talk about this problem and give Ürümqi as an example.

Yes, this is a major omission and MUST be addressed.  In particular, what
are implementations to do in cases where there is any potential ambiguity
like this?  What special security/privacy considerations might apply?

Since tz explicitly avoids defining the geographical boundaries of its
zones for many reasons, including avoiding the appearance of taking sides
in the messier aspects of geopolitics, I'm personally not entirely
convinced it is possible to fully resolve these sorts of issues, nor that
attempting to standardize them in an Internet Draft is entirely wise.
There are several related, equally obscure, edge cases where asking "what
time is it here?" does not (and arguably should not) yield a clear answer
with any semblance of authority behind it.  The more relevant question is
more accurately phrased as: "Which vaguely-but-not-strictly-geographical
group do you agree with in the context of this particular event?"

Because this draft has sat for a while, once some attempts have been made
to actually address these particular concerns, I strongly recommend another
solicitation be made to the full list over at tz to review the draft, with
specific call-outs (copied verbatim, if necessary) to the relevant sections
that address this.  I feel the current group here on tzdist-bis is too
small to recall all the various cases which exist or have existed around
the world, consider how this process might apply to each, and reach
meaningful consensus.  (e.g., I know there's plenty I'm forgetting at the
moment, but I'm only just starting to grapple with this myself, as I know
deep down that reality is nowhere near as simple as the current draft makes
it out to be.)

--
Tim Parenti

---

From: Tim Parenti <[email-masked]>
Date: Sun, 21 Oct 2018 00:54:01 -0400

On Sun, 21 Oct 2018 at 00:23, Tim Parenti <[email-masked]> wrote:

> (e.g., I know there's plenty I'm forgetting at the moment, but I'm only
> just starting to grapple with this myself, as I know deep down that reality
> is nowhere near as simple as the current draft makes it out to be.)
>

Of course, as soon as I sent my previous message, I re-read Lester's
message, which jogged my memory of another one of those edge cases…

> changes of timezone for locations not currently covered by a TZ rule set?

India and Bangladesh share a complex border… and partly in an effort to
simplify it somewhat, the two nations swapped over 150 enclaves in 2015:
https://www.bbc.com/news/world-asia-33033342

Nominally, at the time of the swap, many points on earth which had followed
Asia/Kolkata (observing UTC+05:30) would have started following Asia/Dhaka
(observing UTC+06) and vice-versa.  In actual practice, of course, what
happened in any given household or community is unknown.  Quite plausibly,
given the number of second- and third-order enclaves, groups have organized
and re-organized themselves as needed, aligning their clocks in a manner
that approximates the national borders more roughly than rigidly.

tz does not attempt to model this sort of thing at all, as the borders
themselves are out-of-scope for timezone definitions.  Again, "which
vaguely-but-not-strictly-geographical group do you [happen to] agree with,"
whether out of convenience, persuasion, or political/patriotic inclination?

But any protocol attempting to fully map points on earth to tz zones would
need to have a more robust solution at-hand.

--
Tim Parenti

---

From: Daniel Migault <[email-masked]>
Date: Sun, 21 Oct 2018 04:56:18 -0400

Hi Paul,

I believe my point was the one raised by Lester, that is providing a
coherent way over time to bind geo location and time zone. I was assuming
that we were able to associate the geo location to a time zone at any time.
I see this extending the draft to perform a binding between ((geoloc), tz)
to ((geoloc, time), tz).

The second point you raised is how to solve cases when binding a geoloac to
a tz is not possible or difficult. Maybe considering the structure of the
geoloc may help to classify the different type of confusions. The goeloc is
composed of a point and a radius. The confusion may come from the point or
the radius.
* If the point cannot be associated to a single time zone. I do not think
we can reasonably make a choice, and two different tz may be returned as
equal.
* if the radius covers multiple zone, then we may return the main response
as being associated to the point and alternate choice associated to the
radius.

So I am wondering if providing the two subsets would help.

Yours,
Daniel

On Fri, Oct 19, 2018 at 1:21 PM Paul Eggert <[email-masked]> wrote:

> _______________________________________________
> Tzdist-bis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tzdist-bis
>

---

From: Ken Murchison <[email-masked]>
Date: Sun, 21 Oct 2018 08:17:18 -0400

The geo: URI already has a facility for specifying a radius of 
uncertainty, and the draft includes such an example.

On 10/21/18 4:56 AM, Daniel Migault wrote:
> coherent way over time to bind geo location and time zone. I was 
> assuming that we were able to associate the geo location to a time 
> zone at any time. I see this extending the draft to perform a binding 
> between ((geoloc), tz) to ((geoloc, time), tz).
>
> The second point you raised is how to solve cases when binding a 
> geoloac to a tz is not possible or difficult. Maybe considering the 
> structure of the geoloc may help to classify the different type of 
> confusions. The goeloc is composed of a point and a radius.. The 
> confusion may come from the point or the radius.
> * If the point cannot be associated to a single time zone. I do not 
> think we can reasonably make a choice, and two different tz may be 
> returned as equal.
> * if the radius covers multiple zone, then we may return the main 
> response as being associated to the point and alternate choice 
> associated to the radius.
>
> On Fri, Oct 19, 2018 at 1:21 PM Paul Eggert <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     [email-masked] <mailto:[email-masked]>

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Daniel Migault <[email-masked]>
Date: Sun, 21 Oct 2018 08:50:24 -0400

Thanks for the response. I agree that the radius is not something new. My
point was mostly to distinguish between a tz provided because multiple time
zones could be associated to a single location (the point) or because there
are surrounding tz in the radius. I was suggesting to distinguish the
reason for the additional time zones.

Yours,
Daniel

On Sun, Oct 21, 2018 at 8:17 AM Ken Murchison <[email-masked]> wrote:

> The second point you raised is how to solve cases when binding a geoloac
> to a tz is not possible or difficult. Maybe considering the structure of
> the geoloc may help to classify the different type of confusions. The
> goeloc is composed of a point and a radius.. The confusion may come from
> the point or the radius.
> Tzdist-bis mailing [email-masked]://www.ietf.org/mailman/listinfo/tzdist-bis
>
> --
> Ken Murchison
> Cyrus Development Team
> FastMail US LLC
>

---

From: Paul Eggert <[email-masked]>
Date: Sun, 21 Oct 2018 12:29:40 -0700

> I see this extending the draft to perform a binding between ((geoloc), tz)

Unfortunately I still don't understand your point. Can you provide a specific 
example or two to clarify your point?

For example, if the geolocation is in Ürümqi, China, a server should return both 
Asia/Urumqi and Asia/Shanghai, as both are plausible results. There is no reason 
for the geolocation request to specify a historical timestamp, as Asia/Urumqi 
and Asia/Shanghai are plausible results no matter what historical timestamp the 
client is interested in.

As another example, if the geolocation is in Punta Arenas, Chile, a server 
should return America/Punta_Arenas no matter what historical timestamp the 
client is interested in, and should not return America/Santiago. This is because 
America/Punta_Arenas contains a complete history of timestamps, including 
timestamps predating the creation of the America/Punta_Arenas timezone in the 
tzdb database (and which equal the timestamps for America/Santiago for that period).

So I'm still not seeing why a timestamp should appear in the geolocation 
request, other than as a sort of "metarequest" that would be out of scope for 
this spec. The spec is about questions like "what's the time zone history for 
location L?", not questions like "what did tzdb look like at time T?".

---

From: Doug Royer <[email-masked]>
Date: Sun, 21 Oct 2018 14:56:29 -0600

On 10/19/2018 05:08 AM, Daniel Migault wrote:
> * It seems that the association between a time zone name and a location 
> may change over time.. It seems that the current draft assumes the date 
> is the current time. I am wondering if we are willing to introduce a 
> date parameter (default to current) or not in the current extension. If 
> we don't I believe we should position the current extension. In other 
> will we have to design a new extension from scratch or could we re-use 
> this extension.
> 
> considering different time change. I believe the draft may document this 
> as well. Will we have always different time zone name in that case ?

I admit I have not been following the details of this spec.

I do seem to remember that timezone data has effective dates in them. 
Have they been removed? It was in the tzdata and VTIMEZONE. So, yes you 
can extract the actual time it was and relate it over history.

Also, my mobile carrier has on multiple instances, given me a DHCP IP 
address that has been GEO-located several hundred miles from the 
location of my phone. And in one instance the DHCP IP address provided 
to my phone was over 2,500 miles away, and 2 time zones away.

Example, I posted from Montana, yet facebook geo-location data declared 
it to be in Florida. When I noticed, I sent myself an email and later 
looked at the IP addresses in the email. Yep, the DHCP address I got was 
associated with one of their systems in Florida, over 2,500 miles away.

-- 

Doug Royer - (http://DougRoyer.US  http://goo.gl/yrxJTu )
[email-masked]
714-989-6135

---

From: Lester Caine <[email-masked]>
Date: Mon, 22 Oct 2018 00:34:41 +0100

On 21/10/2018 20:29, Paul Eggert wrote:
> request, other than as a sort of "metarequest" that would be out of 
> scope for this spec. The spec is about questions like "what's the time 
> zone history for location L?", not questions like "what did tzdb look 
> like at time T?".

This makes two assumptions. All the variations in time offset are 
available as individual timezones ... so one can't use TZ since it 
combines areas that have different pre-1970 data! In the future every 
change of offset due to movement of locations between different rule 
sets will be mapped by different rule sets in the what ever database is 
providing them. I don't particularly like the 'date' option to look for 
historic changes to the reported time zone it is at least better than 
nothing, and since no one can guarantee data prior to 1970 is right 
anyway, how can one map differences that are NOT supported in TZ?

---

From: Paul Eggert <[email-masked]>
Date: Sun, 21 Oct 2018 23:57:58 -0700

Doug Royer wrote:
> I do seem to remember that timezone data has effective dates in them. Have they 
> been removed?

Nothing has been removed from the tzdb data. But it's not clear what you mean by 
the phrase "effective dates". If you mean, for example, "When did the US change 
from pre-2007 to post-2007 daylight saving rules?" then no, that effective date 
is not in tzdb (and never has been). If you mean "When are US clocks falling 
back in 2018?" then yes, that effective date is in tzdb and obviously needs to 
stay there. If you mean "When was the post-2007 US rule change put into a tzdb 
release?" then no, that effective date has never been part of the tzdb data. 
There are other reasonable ways to interpret the phrase "effective date", so the 
answer to your question depends on what you meant by "effective date".

---

From: Paul Eggert <[email-masked]>
Date: Mon, 22 Oct 2018 00:21:09 -0700

Lester Caine wrote:
> one can't use TZ since it combines areas that have different pre-1970 data!

I assume by "TZ" you mean "the current version of tzdb" and yes, by design tzdb 
doesn't bother with splitting regions into subregions if the subregions differ 
only in pre-1970 data. No comprehensive data source does that now, and none is 
ever likely to do so, for reasons alluded to in 
<https://data.iana.org/time-zones/theory.html#accuracy>.

> In the future every change of offset due to movement of locations between 
> different rule sets will be mapped by different rule sets in the what ever 
> database is providing them.

Sorry, I don't know what you mean by this. At any rate in practice such changes 
are typically not a problem with tzdb. For example, the 2018f release of tzdb 
introduced the fact that Volgograd is moving time zones (from +03 to +04 on 
October 28) and this was a simple two-line change to a single Zone, with no Rule 
lines changed. See 
<https://github.com/eggert/tz/commit/db8b5f59c3a4d2fcc9b95b702f24f47e3d9857ba>.

> I don't particularly like the 'date' option to look 
> for historic changes to the reported time zone it is at least better than 
> nothing, and since no one can guarantee data prior to 1970 is right anyway, how 
> can one map differences that are NOT supported in TZ?

One cannot. This question is out of scope for this spec, and we shouldn't try to 
contort the spec to bring it into scope, as that would be a lot of work with 
zero existing implementation experience. This spec is not for inventing a new 
system to deal with metadata; it is for specifying existing practice with data.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 22 Oct 2018 09:53:19 +0200

Just for illustration of Paul's point:

On 22.10.18 08:57, Paul Eggert wrote:
>> Have they been removed?
> Nothing has been removed from the tzdb data. But it's not clear what
> you mean by the phrase "effective dates". If you mean, for example,
> "When did the US change from pre-2007 to post-2007 daylight saving
> rules?" then no, that effective date is not in tzdb (and never has
> been). If you mean "When are US clocks falling back in 2018?" then
> yes, that effective date is in tzdb and obviously needs to stay there.
> If you mean "When was the post-2007 US rule change put into a tzdb
> release?" then no, that effective date has never been part of the tzdb
> data. There are other reasonable ways to interpret the phrase
> "effective date", so the answer to your question depends on what you
> meant by "effective date".

What is in the database is this:

Rule    US      1987    2006    -       Apr     Sun>=1  2:00    1:00    D
Rule    US      2007    max     -       Mar     Sun>=8  2:00    1:00    D
Rule    US      2007    max     -       Nov     Sun>=1  2:00    0       S

What is not in the *formal* part of the database is the date those
entries were made, although there is often a comment containing a
reference, and certainly the effective date of whatever legislation or
other that dictated the entry is not there.

Eliot

---

From: Lester Caine <[email-masked]>
Date: Mon, 22 Oct 2018 10:01:48 +0100

On 22/10/2018 08:21, Paul Eggert wrote:
> I assume by "TZ" you mean "the current version of tzdb" and yes, by 
> design tzdb doesn't bother with splitting regions into subregions if the 
> subregions differ only in pre-1970 data. No comprehensive data source 
> does that now, and none is ever likely to do so, for reasons alluded to 
> in <https://data.iana.org/time-zones/theory.html#accuracy>.

That ONE database does not make any attempt to provide accurate historic 
data is no reason to design out the possibility of a cleaner historic 
data source being provided. But simply ensuring that ALL the verified 
pre-1970 data is included as standard or identifying when it is not 
would be better going forward. Will the areas around the UK return 
simply 'Europe/London' or their proper local rule sets hidden in 
backzone? How will we know?

>> In the future every change of offset due to movement of locations 
>> between different rule sets will be mapped by different rule sets in 
>> the what ever database is providing them.
> 
> Sorry, I don't know what you mean by this. At any rate in practice such 
> changes are typically not a problem with tzdb. For example, the 2018f 
> release of tzdb introduced the fact that Volgograd is moving time zones 
> (from +03 to +04 on October 28) and this was a simple two-line change to 
> a single Zone, with no Rule lines changed. See 

Again, accurate verified information as to when individual towns moved 
from local time to a centrally set time is available and the coverage 
provided by that data is growing as more historic records get 
transcribed. As for your example, have you verified proof that all 
locations currently using 'Volgograd' are actually going to follow the 
move? At least in the future it is highly likely that rule sets would 
have to split to support your model, and as older data is verified, 
which TZ will only record in backzone, then again splits of zones would 
be required, while a mechanism that allows the geolocate to select the 
appropriate pre-1970 information would at least allow us to fill a hole 
that TZ has no intention of providing.

>> I don't particularly like the 'date' option to look for historic 
>> changes to the reported time zone it is at least better than nothing, 
>> and since no one can guarantee data prior to 1970 is right anyway, how 
> One cannot. This question is out of scope for this spec, and we 
> shouldn't try to contort the spec to bring it into scope, as that would 
> be a lot of work with zero existing implementation experience. This spec 
> is not for inventing a new system to deal with metadata; it is for 
> specifying existing practice with data.

It was not out of scope for tzdist which provides for more accurate data 
providers, and so this RFC should at least allow those providers to 
provide all time information such as the date when a location moved to 
standardised time. Trying to hamstring the whole system to only support 
the last 40 or so years may be a quick cop out because its easier, but 
it also makes the work of historians a lot more difficult.

At the very least, some mechanism should be included to identify the 
date at which a location started using the PROVIDED tz rule set so that 
we know just when the data is valid from ... and can then look for other 
sources of more accurate earlier data! Personally I have always expected 
that geolocate would return more than 'just' a single identifier simply 
because the currently available data is documented to be incomplete.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 22 Oct 2018 11:13:16 +0200

Hi Lester,

On 22.10.18 11:01, Lester Caine wrote:
> That ONE database does not make any attempt to provide accurate
> historic data is no reason to design out the possibility of a cleaner
> historic data source being provided. But simply ensuring that ALL the
> verified pre-1970 data is included as standard or identifying when it
> is not would be better going forward. Will the areas around the UK
> return simply 'Europe/London' or their proper local rule sets hidden
> in backzone? How will we know? 

Does there exist a database where we *do* have verified pre-1970 data? 
If not, your point is academic.  On the other hand, we should avoid
encoding dates into standards.

Eliot

---

From: Lester Caine <[email-masked]>
Date: Mon, 22 Oct 2018 10:51:33 +0100

> Does there exist a database where we*do*  have verified pre-1970 data?

TZ database has a lot of localized accurate data that is now hidden from 
most distributions and there is no indication if it is included or not! 
Recently further updates were added to pre-1970 data but without looking 
at the raw information one would not know if it is included in a 
distribution!

tzdist provides a perfect mechanism to correctly handle the accuracy of 
the data and I would still prefer that using TZ as a source tagged ALL 
returned rule sets with a start date of 1970 since anything prior to 
that may not include the real data. Returning known invalid data is 
simply not acceptable!

YES we need a much more comprehensive database of pre-1970 data and 
tzdist was specifically expanded to allow that to be created. That TZ 
has no interest in supporting this is not a problem, but tzdist is 
allowed to have a more accurate return of data and material related to a 
specific location was push out of tzdist as something to be covered by 
geolocate. To now hamstring even geolocate with proven invalid data is 
taking things too far. At the very least we have historic information as 
to local time for every location which is specifically excluded from TZ 
rule sets for obvious reasons, but can be included in a more complete 
geolocate service.

geolocate return should give a publisher along with an identifier, or 
alternatively we ask for the identifier for a specific publisher in 
which case use the tzdist mechanism to identify the source comes in? But 
it DOES make sense that asking for an identifier for say 1939 will 
return a NULL record if the publisher does not support that date. It 
seems rather convoluted that one looks up an identifier and then check 
that the tzdist data actually supports it? We are not looking to encode 
dates into the standard, simply provide a mechanism such as included in 
tzdist that identifies if the data is valid for the search.

---

From: Daniel Migault <[email-masked]>
Date: Mon, 22 Oct 2018 10:34:57 +0000

Hi Paul, 

Thanks for the follow up. So my expectation would be that:

Suppose I am in 2018 in Punta Arenas:
* when I request what is my local TZ for my dinner I expect to receive America/Punta_Arenas
* when I look back in 2016 what I did last time, I would like to make sure time is considering America/Santiago. 

Suppose I am in Ürümqi in 2018 in 2018:
* I should get both Asia/Urumqi and Asia/Shanghai. There is no way to decide.
* When I will be back in Ürümqi after they agree on a single TZ, I would like my 2018 events remain associated to the two TZ.

Now, it could be the use cases that need the time are not relevant. 
*  If requests for TZ are only intended for a mobile phone to have the right time. I understand we do not need to specify the time associated to the geoloc. As we do not use time in DNS or DHCP.
* I assume that TZ has not been loaded in the past. This may never happen, or there may be other ways, to retrieve the appropriated TZ of 2016 from the uploaded TZ in 2018. 
* Similarly, specification of the time may be more in the scope of a generic search API... and thus out of scope.  

Yours, 
Daniel

-----Original Message-----
From: Paul Eggert <[email-masked]> 
Sent: Sunday, October 21, 2018 3:30 PM
To: Daniel Migault <[email-masked]>
Cc: [email-masked]
Subject: Re: [Tzdist-bis] draft-tzdist-geolocate

Daniel Migault wrote:
> assuming that we were able to associate the geo location to a time zone at any time.
> I see this extending the draft to perform a binding between ((geoloc), 
> tz) to ((geoloc, time), tz).

Unfortunately I still don't understand your point. Can you provide a specific example or two to clarify your point?

For example, if the geolocation is in Ürümqi, China, a server should return both Asia/Urumqi and Asia/Shanghai, as both are plausible results. There is no reason for the geolocation request to specify a historical timestamp, as Asia/Urumqi and Asia/Shanghai are plausible results no matter what historical timestamp the client is interested in.

As another example, if the geolocation is in Punta Arenas, Chile, a server should return America/Punta_Arenas no matter what historical timestamp the client is interested in, and should not return America/Santiago. This is because America/Punta_Arenas contains a complete history of timestamps, including timestamps predating the creation of the America/Punta_Arenas timezone in the tzdb database (and which equal the timestamps for America/Santiago for that period).

So I'm still not seeing why a timestamp should appear in the geolocation request, other than as a sort of "metarequest" that would be out of scope for this spec. The spec is about questions like "what's the time zone history for location L?", not questions like "what did tzdb look like at time T?".

---

From: Paul Eggert <[email-masked]>
Date: Mon, 22 Oct 2018 09:00:41 -0700

> * when I look back in 2016 what I did last time, I would like to make sure time is considering America/Santiago.

If in 2016 you recorded the UT offset you can reuse that offset now. If 
in 2016 you recorded the string "America/Santiago" you can reuse that TZ 
setting now, and get what it means now; typically it will mean the same 
thing for old timestamps that it meant back in 2016, though we do 
correct errors occasionally so this is not guaranteed. However, if you 
want to know *now* what tzdb looked like *in 2016*, you're out of luck. 
That information is not available and no system that I know of makes it 
available.

> * When I will be back in Ürümqi after they agree on a single TZ, I would like my 2018 events remain associated to the two TZ.

The former sounds right. The latter should work, as tzdb doesn't remove 
names of timezones that differed after 1970.

---

From: Paul Eggert <[email-masked]>
Date: Mon, 22 Oct 2018 10:06:28 -0700

On 10/22/18 2:01 AM, Lester Caine wrote:
> historic data source being provided.

The information you're asking for can be supplied in the data provided 
by the tzdist protocol (RFC 7808), which maps tzdb names to data. 
tzdist-geolocate itself does not need to worry about this, as it just 
maps geolocations to tzdb names.

> But simply ensuring that ALL the verified pre-1970 data is included as 
> standard or identifying when it is not would be better going forward. 
> Will the areas around the UK return simply 'Europe/London' or their 
> proper local rule sets hidden in backzone? How will we know?

None of these questions are tzdist-geolocate's job. Its job is to 
provide a protocol that maps geolocations to tzdb names. Which tzdb 
names to use is out of scope.

> accurate verified information as to when individual towns moved from 
> local time to a centrally set time is available and the coverage 
> provided by that data is growing as more historic records get transcribed.

Which project is this? I haven't heard of it. Is its data's coverage 
being made via tzdist or something like tzdist? Do you have a URL for 
the project?

> have you verified proof that all locations currently using 'Volgograd' 
> are actually going to follow the move?

The Volgograd entry contains a prediction for a future event (October 
28) and like all predictions it might be wrong. However, tzdb cites a 
law <http://publication.pravo.gov.ru/Document/View/0001201810110037> 
recently passed by the relevant legislative body for the Volgograd 
oblast and in the past this sort of thing has stood up reasonably well 
for Russian time zone changes.

> At least in the future it is highly likely that rule sets would have 
> to split to support your model, and as older data is verified, which 
> TZ will only record in backzone, then again splits of zones would be 
> required

Splits are needed only if clocks in a region disagree after 1970. They 
are not needed in tzdb if clocks disagree only before 1970. If someone 
wants to build a database where the cutoff is earlier than 1970 then of 
course they are free to do so. But nobody is volunteering or is likely 
to volunteer for that job.

> TZ database has a lot of localized accurate data that is now hidden 
> from most distributions

Not really. Few zones are in that category: just Belfast, Jersey, 
Guernsey, and the Isle of Man. Most entries in tzdb's 'backzone' file 
are unverified by anything other than Shanks, a notoriously unreliable 
source. Many of the entries are even known to be wrong, and nobody cares 
to fix them.

'backzone' is just a proof-of-concept with some examples that show that 
the format *could* push the cutoff back to before 1970, if someone had 
the time and the data to do it; but nobody does.

---

From: Lester Caine <[email-masked]>
Date: Mon, 22 Oct 2018 22:02:08 +0100

> source. Many of the entries are even known to be wrong, and nobody cares 

Why would anybody even bother these days when the time spent is simply 
wasted? I should know I'm one of the people who wasted the time to fix 
errors that had screwed up historic information ... and now those errors 
are published as facts! geolocate should return identifiers that can be 
relied on to provide factual information ...

---

From: Ken Murchison <[email-masked]>
Date: Wed, 24 Oct 2018 11:50:34 -0400

> between ((geoloc), tz) to ((geoloc, time), tz).

While I agree (as I have in the past) that having a method to fetch 
older time zone data is useful, I don't believe that it should be wedged 
into geolocate.  geolocate is really just a filter on the TZDIST 'list' 
action, similar to the 'find' action. Where 'find' asks for the subset 
of tzids that match a given pattern, geolocate asks for the subset of 
tzids that contain/overlap a given point/area.

As I have mentioned before, I believe that any TZDIST facility to 
request older/previous time zone data should be a separate extension, 
which could then be leveraged by geolocate, and the rest of the TZDIST 
actions.

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Eliot Lear <[email-masked]>
Date: Wed, 24 Oct 2018 17:55:25 +0200

Hi Ken,

On 24.10.18 17:50, Ken Murchison wrote:
> older time zone data is useful, I don't believe that it should be
> wedged into geolocate.  geolocate is really just a filter on the
> TZDIST 'list' action, similar to the 'find' action.  Where 'find' asks
> for the subset of tzids that match a given pattern, geolocate asks for
> the subset of tzids that contain/overlap a given point/area.
>

To say just a few more sentences, and maybe I'm missing the point, but
the reasoning I perceive for this work is so mobile devices can fetch
time zone information relative to where they are now.  Moreover, would I
be wrong to say that the tzdist mechanism doesn't work that well to
reduce data on a system if we don't have such a mechanism?

Is that not correct?

Eliot

---

From: Matthew Donadio <[email-masked]>
Date: Wed, 24 Oct 2018 12:05:08 -0400

> reduce data on a system if we don't have such a mechanism?

Problems with historical data aside, I have museum friends / archivists who
would probably be interested in this as they work on back-annotating their
collections.  Data would either be from the EXIF in the images directly or
in the DAMS / collections management system.

--Matthew Donadio ([email-masked])

---

From: Eliot Lear <[email-masked]>
Date: Wed, 24 Oct 2018 18:08:08 +0200

Matthew,

On 24.10.18 18:05, Matthew Donadio wrote:
> Problems with historical data aside, I have museum friends /
> archivists who would probably be interested in this as they work on
> back-annotating their collections.  Data would either be from the EXIF
> in the images directly or in the DAMS / collections management system.

Yes, I think that is also (at least in part) Lester's use case if I'm
not mistaken.  The question is whether you need a protocol for that
purpose or merely a software capability that can consume the TZDB and
perhaps other information.  In answering this question it boils down to
who will write the implementation.

Eliot

---

From: Ken Murchison <[email-masked]>
Date: Wed, 24 Oct 2018 12:09:43 -0400

On 10/24/18 11:55 AM, Eliot Lear wrote:
> time zone information relative to where they are now.

Correct.

>    Moreover, would I

I wouldn't say that it doesn't work well without it, but it can enhance 
its ability to be useful.  For instance, if I'm in New York City, I can 
simply tell my device to fetch tzid America/New_York and the client does 
this with a simple TZDIST 'get' action.  If I'm hiking through 
Tennessee, I may not know whether I'm in US/Eastern or US/Central since 
its splits the state.

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Ken Murchison <[email-masked]>
Date: Wed, 24 Oct 2018 12:22:10 -0400

> So I am wondering if providing the two subsets would help.

I forgot to answer the second point.  I agree that it would be useful to 
annotate which zone(s) contain the specified point and which zone(s) 
overlap the radius of uncertainty.

Because the response to a geolocate request is a JSON array of objects, 
we could add a new field to each zone object with whatever proximity 
data we want.  I'm open to suggestions.  It could be something as simple 
as a boolean value specifying whether the time zone contains the point, 
or it could be a distance from the point (0.0m means it contains the 
point), or maybe even a vector from the point to where the time zone 
crosses the radius of uncertainty.

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Daniel Migault <[email-masked]>
Date: Wed, 24 Oct 2018 12:25:36 -0400

It seems to me a boolean value "You are here" woudl be easier to implement
and probably more reliable. But that is just my thoughts.
Yours,
Daniel

On Wed, Oct 24, 2018 at 12:22 PM Ken Murchison <[email-masked]> wrote:

> Because the response to a geolocate request is a JSON array of objects, we
> could add a new field to each zone object with whatever proximity data we
> want.  I'm open to suggestions.  It could be something as simple as a
> boolean value specifying whether the time zone contains the point, or it
> could be a distance from the point (0.0m means it contains the point), or
> maybe even a vector from the point to where the time zone crosses the
> radius of uncertainty.
>
>
>
>

---

From: Daniel Migault <[email-masked]>
Date: Wed, 24 Oct 2018 12:28:00 -0400

Thanks you all for answering my point. I agree that including time woudl be
out of scope of this extension. I appreciated the detaille dresponses.
Yours,
Daniel

On Wed, Oct 24, 2018 at 12:25 PM Daniel Migault <[email-masked]>
wrote:

>> response as being associated to the point and alternate choice associated
>> to the radius.
>>
>> we could add a new field to each zone object with whatever proximity data
>> we want.  I'm open to suggestions.  It could be something as simple as a

---

From: Daniel Migault <[email-masked]>
Date: Wed, 24 Oct 2018 12:36:15 -0400

I believe we could have a consensus on the next version, and start the WGLC
on November 5.

Here is my view on the draft status.
* Maybe clarifying the scope of the draft. I believe that one sentence
could clearly mention the draft does not expect to go beyond a mobile phone
requesting the current TZ.
* Raising a privacy issue and recommend of using the extension over TLS or
a protected channel.
* Having a discussion on whether we specify the time zones associated to
the point or not and how to do this. While this needs some discussions, I
believe we could converge rapidly.

It would also be helpful to know if there are known implementations or
people planning to implement it. I hope this will be implemented soon!

Of course if you have other comments, please raise them!

Yours,
Daniel

---

From: Ken Murchison <[email-masked]>
Date: Wed, 24 Oct 2018 12:43:59 -0400

On 10/24/18 12:36 PM, Daniel Migault wrote:
> I believe we could have a consensus on the next version, and start the 
> WGLC on November 5.
>
> could clearly mention the draft does not expect to go beyond a mobile 
> phone requesting the current TZ.

Probably "mobile device" (not necessarily a phone), yes?

> * Raising a privacy issue and recommend of using the extension over 
> TLS or a protected channel.

I believe privacy is discussed in the main TZDIST spec (RFC 7808, 
Section 8).  Is referencing this sufficient?

> * Having a discussion on whether we specify the time zones associated 
> to the point or not and how to do this. While this needs some 
> discussions, I believe we could converge rapidly.

Agreed.  I'm open to any and all suggestions.

> people planning to implement it. I hope this will be implemented soon!

I have an implementation in the open source Cyrus Calendar server.  The 
examples in the draft where generated using that server.

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Daniel Migault <[email-masked]>
Date: Wed, 24 Oct 2018 12:56:01 -0400

Hi Ken,

I agree, please see my comments.

Yours,
Daniel

> Probably "mobile device" (not necessarily a phone), yes?
<mglt>yes ;-) I agree. </mglt>

> <mglt>I think the security consideration is fine - my mistake.. I was
referring to the privacy section in fact. I would re-enforced in that
section the use of TLS (MUST) as the geolocalisation is in my point of view
present a higher degree of privacy than the data we dealt with in
RFC7808.</mglt>

> Agreed.  I'm open to any and all suggestions.
<mglt>I hope the WG will provide feed backs.</mglt>

---

From: Lester Caine <[email-masked]>
Date: Wed, 24 Oct 2018 20:01:04 +0100

> who will write the implementation.

This is not really a matter of 'writing an implementation', but simply 
defining what happens when a time and location stamp is processed. 
Handling uncertainty as to just which ident IS correct needs to be part 
of that process?

Images with a location, are then normalized time wise using the current 
offset for that location. In N years time provided that the offset has 
not changed then everything is fine, but if any element of selecting the 
offset has changed this may not be the case. geolocate may well be 
giving a different tz identifier as has been demonstrated, and in 
addition the rule set that was used originally may have been 'corrected' 
for some reason so one needs to know in addition to the location and 
time, the versions of data used to generate the offset! SIMPLY asking 
for the current identifier associated with a location in Paul's model 
requires that the identifier does not change at all over time ... only 
the rules set changes and tzdist's ability to monitor changes over time 
solves the problem of whether an historic normalized timestamp can be 
relied on. If geolocate returns a different identifier then the tzdist 
may not be able to help? If there is uncertainty as to the correct 
offset then at least recording what rule was used allows historians to 
pick up on the problem and perhaps correct just what geolocate should 
have returned?

An historic tag has to consist of location, UTC time, tz publisher, zone 
identifier and version. Simply storing a location, UTC time and offset 
as some databases currently do may work for today, but in N years time 
we once again have an element of uncertainty if the current rule set for 
the location does not match that used previously. In my book, the 
problem comes when pre-1970 material for which we know accurate times is 
messed up because geolocate only returns post-1970 identifiers without 
any warning that the data then accessed from tzdist IS going to be wrong!

---

From: Guy Harris <[email-masked]>
Date: Wed, 24 Oct 2018 15:47:49 -0700

On Oct 24, 2018, at 9:43 AM, Ken Murchison <[email-masked]> wrote:

>> I believe we could have a consensus on the next version, and start the WGLC on November 5.
>> 
>> * Maybe clarifying the scope of the draft. I believe that one sentence could clearly mention the draft does not expect to go beyond a mobile phone requesting the current TZ.
> 

The draft itself says

   Clients using a Time Zone Data Distribution Service (TZDIST),
   particularly mobile clients, may not have prior knowledge of which
   time zone is appropriate for a particular geographic region.

in the introduction, so "mobile client", perhaps?

Or is the goal here to clarify what a "mobile client" is?  If so, it needs to include laptop computers, even if some might not deem them "devices".

---

From: Ken Murchison <[email-masked]>
Date: Wed, 24 Oct 2018 18:56:02 -0400

> Or is the goal here to clarify what a "mobile client" is?  If so, it needs to include laptop computers, even if some might not deem them "devices".

Good catch.  So, this does beg the question as to how to the scope needs 
to be further clarified.  Daniel, do you have some suggested text?

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Daniel Migault <[email-masked]>
Date: Thu, 25 Oct 2018 12:40:45 +0200

Will have a look at the draft and see why i went off trak.. if anything
should be changed.
Yours
Daniel

On Thu, Oct 25, 2018, 00:56 Ken Murchison <[email-masked]> wrote:

> > Or is the goal here to clarify what a "mobile client" is?  If so, it
> needs to include laptop computers, even if some might not deem them
> "devices".
>
>

---

From: Daniel Migault <[email-masked]>
Date: Thu, 25 Oct 2018 08:55:08 -0400

Hi,

So first of all everything needs to be taken with a pinch of saltz, as
English is not my native language. I am providing text as a way to point
out my miss understanding. I might be wrong and if you believe the previous
text was better I am fine with it. I hope it helps and this is just a
suggestion.

Yours,
Daniel

here are my comments:

Abstract
OLD text:
   This document defines an extension to the Time Zone Data Distribution
   Service (RFC 7808) to allow a client to determine the correct time
   zone for a geographic point location using a 'geo' URI (RFC 5870).

I propose s/client/mobile device/

It is not that client is wrong, but my interpretation was client in a
client - server
relation, which could include other clients than those on a mobile device. So I
believe such change clarify the context here.

OLD text:
   Clients using a Time Zone Data Distribution Service (TZDIST),
   particularly mobile clients, may not have prior knowledge of which
   time zone is appropriate for a particular geographic region.  This
   specification defines a new TZDIST service action to allow a client
   to query a server with a geographic point location and have that
   server determine if the location lies within the boundaries of an
   existing time zone and return the corresponding time zone identifier.

The Clients of the TZDIST considers "history", while this extension
does not consider it. Thus it might be good to specify we are addressing
two different sets of clients. I understand "particularly" as this concerns
mobile clients, but we do not limit it to these mobile devices, which
is what we do.

I would propose:

Updating tie zones with Time Zone Data Distribution (TZDIST)
requires a prior knowledge of the time zone identifier. Such prior
knowledge may be inconvenient for mobile device that are likely
to change their time zone as they are moving and changing their
geographic location.
This specification defines a new TZDIST service action to allow a
client on a mobile
device to retrieve the time zone identifier associated its current location.

The server may provide a single or multiple time zone identifiers
based on the context.
Typically, when the mobile device is at the boundaries of multiple
time zones, the server may
return the surrounding time zones as well. In addition, some other
areas use multiple time zones.
In order to ease the handling of multiple time zones by the mobile
device, the server
indicates the time zones associated to the geographic location from
the surrounding ones.

The current text misses "if the location lies within the boundaries of an
existing time zone". It seems that some locations are not associated
to time zones.
If that is correct we may re-add it.

On Thu, Oct 25, 2018 at 6:40 AM Daniel Migault <[email-masked]>
wrote:

>> >>> * Maybe clarifying the scope of the draft. I believe that one
>> sentence could clearly mention the draft does not expect to go beyond a
>> mobile phone requesting the current TZ.