Subject: [Tzdist] Next step

From: Daniel Migault <[email-masked]>
Date: Sun, 18 Oct 2015 17:39:04 +0100

Dear WG,

We have almost compleetd our milestones. We are thus considering two
options in the next future:
    OPTION 1: There is significant interest and energy to work on topics in
this area. In that case, we can think of re-chartering the WG. If you see
any work in this area, let it us know as soon as possible, so we can define
a new charter.
    OPTION 2: The WG will be closed when the RFCs are published; the
mailing list will remain open for any continued discussion.

BR,

Daniel and Eliot

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 19 Oct 2015 09:55:59 -0400

Hi Daniel,

--On October 18, 2015 at 5:39:04 PM +0100 Daniel Migault 
<[email-masked]> wrote:

>     OPTION 1: There is significant interest and energy to work on topics
> in this area. In that case, we can think of re-chartering the WG. If you
> see any work in this area, let it us know as soon as possible, so we can
> define a new charter.

A couple of possible follow-up work items:

1) Add a location->tzid mapping extension to the tzdist protocol. That 
ought to be a relatively trivial extension to define if there is interest.

2) In conjunction with the IANA tzdb folks, define a media type that 
describes the "zoneinfo" file format (either a direct binary representation 
or, say, a JSON representation of that) so that tzdist servers can directly 
provide the zoneinfo file data that many OS's use.

-- 
Cyrus Daboo

---

From: Ken Murchison <[email-masked]>
Date: Mon, 19 Oct 2015 10:00:03 -0400

On 10/19/2015 09:55 AM, Cyrus Daboo wrote:
> describes the "zoneinfo" file format (either a direct binary 
> representation or, say, a JSON representation of that) so that tzdist 
> servers can directly provide the zoneinfo file data that many OS's use.
>

+1 on both ideas.  Cyrus beat me to suggesting them.

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

---

From: Ken Murchison <[email-masked]>
Date: Mon, 19 Oct 2015 10:14:28 -0400

> ought to be a relatively trivial extension to define if there is 

Actually, would this be a mapping from something like "Pittsburgh, PA" 
-> "America/New_York", or from GPS coordinates to a tzid, or both?

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 19 Oct 2015 10:17:55 -0400

Hi Ken,

--On October 19, 2015 at 10:14:28 AM -0400 Ken Murchison 
<[email-masked]> wrote:

> Actually, would this be a mapping from something like "Pittsburgh, PA" ->
> "America/New_York", or from GPS coordinates to a tzid, or both?

I would prefer just geo URI -> tzid, and leave address->geo to some other 
service (since that is useful in a number of other situations - not just 
tzdist).

-- 
Cyrus Daboo

---

From: Daniel Migault <[email-masked]>
Date: Mon, 19 Oct 2015 14:27:18 +0000

Hi, 

I believe one of the first challenge will be to define which bindings are useful, and probably more than one binding may need to be considered.

BR, 
Daniel
-----Original Message-----
From: Tzdist [mailto:[email-masked]] On Behalf Of Ken Murchison
Sent: Monday, October 19, 2015 3:14 PM
To: [email-masked]
Subject: Re: [Tzdist] Next step

On 10/19/2015 09:55 AM, Cyrus Daboo wrote:
>>     OPTION 1: There is significant interest and energy to work on 
>> topics in this area. In that case, we can think of re-chartering the 
>> WG. If you see any work in this area, let it us know as soon as 
>> possible, so we can define a new charter.
>

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

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 19 Oct 2015 11:05:03 -0400

> service (since that is useful in a number of other situations - not just 

It's a separate protocol, and might be more heaviweight than folks would
prefer, but I'd recommend looking at the Location-to-Service-Translation
protocol (LoST), RFC 5222.  It was originally engineered to let people find
the appropriate emergency call center (i.e. 911, 112, 999, etc.) for their
current location.  It's designed to work for both geo and civic addresses.

I'm inclined *not* to say that only geographic coordinates should be
handled, because usually, the semantic of TZIDs maps to civic location
(i.e. "In Tennessee, Roane County uses America/New_York, Cumberland County
uses America/Chicago"), and round-tripping this through geo location can
introduce error.

-- 
Jonathan Lennox
[email-masked]

---

From: Tim Parenti <[email-masked]>
Date: Mon, 19 Oct 2015 11:06:17 -0400

> ought to be a relatively trivial extension to define if there is interest.

+1 to the idea.

> "America/New_York", or from GPS coordinates to a tzid, or both?

Although both would be quite useful, mappings from location strings such as
"Pittsburgh, PA" to geographical coordinates such as 40.44,-79.95 are well
outside the scope of things timezone-related, and that is arguably a space
which is fairly well-serviced by existing APIs.  So I think
coordinates-to-timezone should be sufficient for us, but perhaps we would
want to develop a protocol for other useful mappings.

To be clear, this kind of "mapping" data (if you'll pardon the play on
words) is something the tz (Olson) project has explicitly avoided over the
years, due to the highly political nature of border disputes and the like.
Hopefully it is evident to most on this list that the mapping from location
to timezone is unequivocally NOT one-to-one, despite the appearance in most
cases that it is, but I'll hold off on specific examples unless/until the
WG decides we should explore this path.

Even so, for implementors, Eric Muller's maps at http://efele.net/maps/tz/
are reasonably up-to-date (2013b) and may be a decent starting point for a
service seeking to provide this kind of data.

> provide the zoneinfo file data that many OS's use.

If this is an offshoot from Ticket 34
<http://trac.tools.ietf.org/wg/tzdist/trac/ticket/34> ("should we include a
raw tzdb format media type?"), then +1 to this collaboration as well.

--
Tim Parenti

---

From: Eliot Lear <[email-masked]>
Date: Mon, 19 Oct 2015 20:11:11 +0200

Hi Cyrus,

Coming back to this point:

> servers can directly provide the zoneinfo file data that many OS's use.

So you are talking about /var/share/zoneinfo/..., etc?  In other words,
tzfile.5 in the distribution?

Eliot

---

From: Deborah Goldsmith <[email-masked]>
Date: Mon, 19 Oct 2015 11:50:14 -0700

> 2) In conjunction with the IANA tzdb folks, define a media type that describes the "zoneinfo" file format (either a direct binary representation or, say, a JSON representation of that) so that tzdist servers can directly provide the zoneinfo file data that many OS's use.

Is anyone working with the ICU project to come up with a way to make it and tzdist work together?

Thanks,
Deborah

> On Oct 19, 2015, at 6:55 AM, Cyrus Daboo <[email-masked]> wrote:
> 
> Hi Daniel,
> 
> --On October 18, 2015 at 5:39:04 PM +0100 Daniel Migault <[email-masked]> wrote:
> 
> 1) Add a location->tzid mapping extension to the tzdist protocol. That ought to be a relatively trivial extension to define if there is interest.
> 
> 2) In conjunction with the IANA tzdb folks, define a media type that describes the "zoneinfo" file format (either a direct binary representation or, say, a JSON representation of that) so that tzdist servers can directly provide the zoneinfo file data that many OS's use.
> 
> -- 
> Cyrus Daboo
>

---

From: Doug Royer <[email-masked]>
Date: Mon, 19 Oct 2015 12:56:11 -0600

On 10/19/2015 08:17 AM, Cyrus Daboo wrote:
> I would prefer just geo URI -> tzid, and leave address->geo to some
> other service (since that is useful in a number of other situations -
> not just tzdist).

The database should be separate, political boundaries change and who
would keep up with (example) the city limits of Wells Nevada so the
database can correctly map it to Mountain time when the rest of Nevada
uses Pacific time?

-- 

Doug Royer - (http://K7DMR.us / http://DougRoyer.US)
[email-masked]
714-989-6135

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 19 Oct 2015 14:56:21 -0400

Hi Deborah,

> and tzdist work together?

No - but that is something we talked about at the CalConnect meeting in 
Amsterdam a few weeks ago. I definitely think it would be good to have a 
tzdist client incorporated directly into ICU so anyone using libicu could 
gain the benefit of incremental zoneinfo updates. Obviously there is a lot 
more to it than that - but I think it would be a worthy goal.

There was also talk at some point of having IANA run a tzdist server as a 
way of "bootstrapping" use of the protocol - that might be a pretty big 
commitment if we really wanted it to scale as a "primary" tzdist server.

-- 
Cyrus Daboo

---

From: Doug Royer <[email-masked]>
Date: Mon, 19 Oct 2015 12:59:24 -0600

> -> "America/New_York", or from GPS coordinates to a tzid, or both?

Yes, time zones are defined by political boundary, not Latitude /
Longitude.

--

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 19 Oct 2015 15:00:10 -0400

Hi Doug,

> database can correctly map it to Mountain time when the rest of Nevada

It is true that there are already web services that do that kind of thing 
(see e.g., <http://www.geonames.org/export/web-services.html#timezone>). 
The question is whether that would be valuable for a client to do directly 
along side tzdist - or would we just let them rely on their existing 
"date-time/timezone" picker UI.

-- 
Cyrus Daboo

---

From: Doug Royer <[email-masked]>
Date: Mon, 19 Oct 2015 13:10:37 -0600

On 10/19/2015 01:00 PM, Cyrus Daboo wrote:
> It is true that there are already web services that do that kind of
> thing (see e.g.,
> <http://www.geonames.org/export/web-services.html#timezone>). The
> question is whether that would be valuable for a client to do directly

Postal codes don't always map to time zones. When you live way out in
the country, the postal code can be more than 20 miles away from the
city with the same name.  The postal code is designed to route
snail-mail to your home, not define your physical location.

I know postal codes can cross time zones, city boundaries and perhaps
county boundaries, not aware of any state boundary issue. I picked the
Wells Nevada example for that reason. Some rural residents that live out
of the city limits have Wells zip codes because it is the nearest post
office. And they are not in the same time zone as Wells NV.

That would make the database a real mess to keep up to date.

--

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 19 Oct 2015 15:21:08 -0400

Hi Doug,

> That would make the database a real mess to keep up to date.

Does not use postal codes, uses lat/long. Look at the "Timezone" service at 
the bottom of that page.

Also, I would expect any service like this to be smart about returning 
multiple TZIDs for the case where the lat/long is close to a boundary 
between different time zones or is in an area of "dispute" where multiple 
tzids might be in effect.

Anyway, the point right now is to gauge whether there is any interest in 
supporting a feature like this in tzdist. I am sure we can come up with 
something that works reasonably well if we want to...

-- 
Cyrus Daboo

---

From: Paul Eggert <[email-masked]>
Date: Mon, 19 Oct 2015 18:00:33 -0700

Eliot Lear wrote:
> So you are talking about/var/share/zoneinfo/..., etc?  In other words,

That's my understanding of the proposal, yes. Basically, tzfile.5 on wheels. The 
format is already defined and is widely used; all that's needed is to RFC-ize 
it. (Yes, I know, "all" is sometimes a big word....)

Perhaps there's some call for JSON too, I don't know.

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 19 Oct 2015 21:29:20 -0400

Hi Paul,

--On October 19, 2015 at 6:00:33 PM -0700 Paul Eggert <[email-masked]> 
wrote:

> That's my understanding of the proposal, yes. Basically, tzfile.5 on
> wheels. The format is already defined and is widely used; all that's
> needed is to RFC-ize it. (Yes, I know, "all" is sometimes a big word....)

Right!

> Perhaps there's some call for JSON too, I don't know.

I think the tricky part about tzfile is dealing with the endian and 
32/64-bit differences. I am assuming we would need to serve up all possible 
variants of those if we used the binary format as is. So we could end up 
with, e.g., application/zoneinfo-be-32, application/zoneinfo-le-32, 
application/zoneinfo-be-64, application/zoneinfo-le-64 etc, which seems a 
little clumsy.

With a JSON abstraction of the binary format, clients would need a simple 
tool to convert JSON to the right binary format for their platform, but 
that should be a small amount of code. Obviously the JSON data would be 
larger than the binary equivalent, which might be another downside of using 
it.

-- 
Cyrus Daboo

---

From: Paul Eggert <[email-masked]>
Date: Mon, 19 Oct 2015 19:00:28 -0700

Cyrus Daboo wrote:
> I think the tricky part about tzfile is dealing with the endian and 32/64-bit
> differences. I am assuming we would need to serve up all possible variants of
> those if we used the binary format as is.

That's not a problem, because there's only one binary format. The tzfile format 
is well-defined to be bigendian on all platforms, and to be independent of 
native word size. The reference code to read and write tzfile format is designed 
to work even on unusual machines where words are neither 32 nor 64 bits wide 
(e.g., Unisys mainframes). So there's not much need for a JSON tool to convert 
to "native" format.

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 19 Oct 2015 22:02:52 -0400

Ok, then that greatly simplifies things. So we just define application/zoneinfo and we are pretty much done...

-- 
Cyrus Daboo
(Tapped out on my iPad)

> On Oct 19, 2015, at 10:00 PM, Paul Eggert <[email-masked]> wrote:
> 
> Cyrus Daboo wrote:
> That's not a problem, because there's only one binary format. The tzfile format is well-defined to be bigendian on all platforms, and to be independent of native word size. The reference code to read and write tzfile format is designed to work even on unusual machines where words are neither 32 nor 64 bits wide (e.g., Unisys mainframes). So there's not much need for a JSON tool to convert to "native" format.

---

From: Lester Caine <[email-masked]>
Date: Tue, 20 Oct 2015 07:34:52 +0100

> "date-time/timezone" picker UI.

The problem with using geonames as I see it is that it ONLY provides the
current timezone for a location. Probably perfectly reliable in 99.9% of
cases where the locations historic changes are documented via TZ, but
where areas do move from one timezone to another outside of the TZ
framework there is no mechanism to identify if there was such a change
last year ... or next ... unless TZ *IS* going to add extra zones
covering these 'movements'?

And I make no apology about banging on about historic changes that are
currently selectively distributed via TZ in the form of the backzone
element. It is the pre-1970 area of time where locations may well move
from using one set of timezone data to another and therefore is outside
the scope of TZ. It needs to be clear just where the current time
boundaries are in the data being served!

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

---

From: Eliot Lear <[email-masked]>
Date: Tue, 20 Oct 2015 09:21:54 +0200

Hi Cyrus,

On this point:

> "date-time/timezone" picker UI.

Someone has to want to use the output that is being discussed.  If we
were to hold a BoF on this we would ask the following questions:

1.  Is this important to do?
2.  Is it correct for the IETF to do it?
3.  Is there a draft author?
4.  Are there reviewers?

and I'll add:

5.  If this was done, who would implement?

Really I'd like to hear the answer to 5 first.

And then we have to return to whether or not this is appropriate given LoST.

Eliot

---

From: Tim Parenti <[email-masked]>
Date: Tue, 20 Oct 2015 14:27:30 -0400

On 20 October 2015 at 02:34, Lester Caine <[email-masked]> wrote:

> areas do move from one timezone to another outside of the TZ
> framework
>

Yes, normal borders and border disputes aside, this type of thing is
particularly non-obvious.  For example, when India and Bangladesh exchanged
several enclaves
<https://www.washingtonpost.com/news/worldviews/wp/2015/08/01/say-goodbye-to-the-weirdest-border-dispute-in-the-world/>
this past August, nominally, the borders between Asia/Kolkata (UTC+5:30)
and Asia/Dhaka (UTC+6:00) moved.  Did the clocks in those areas change?
Technically, it would seem so, but the truth on the ground is probably much
more complicated, and it's nominally outside the scope of tz.

In a different type of case, the presence of historical zones could cause
needless complications in calendaring.  For example, my main calendars here
in Pittsburgh all use America/New_York, but for some reason my mobile
provider tells my phone that it's in America/Detroit.  So when I view any
events created on my phone from a web interface, I'm warned to be cautious
since I'm viewing an event in a different time zone, which although
technically true, is mildly annoying considering that there haven't been
any differences between those two zones since 1975.  I'd imagine for
someone, e.g., in Toledo, Ohio using a lot of locations near the border
between America/New_York and America/Detroit, this would be similarly
aggravating, especially since they probably don't think about that as a
time zone border.

Implementations in this area might endeavor to distinguish between "borders
that potentially matter" and "borders that definitely don't matter", which
seems a tenuous distinction.

--
Tim Parenti

---

From: Paul Eggert <[email-masked]>
Date: Tue, 20 Oct 2015 12:08:33 -0700

> seems a tenuous distinction.

On my list of tzdata things to do is to add a file zonenow.tab, which would be 
like zone1970.tab except with the cutoff being now, i.e., it would partition the 
world into regions where civil-time clocks agree from now into the predicted 
future (but may disagree in the past). A server that wants to cater only to 
current and future timestamps could limit itself to zones in zonenow.tab.

---

From: Tim Parenti <[email-masked]>
Date: Wed, 21 Oct 2015 17:34:25 -0400

On 20 October 2015 at 15:08, Paul Eggert <[email-masked]> wrote:

> On my list of tzdata things to do is to add a file zonenow.tab, which
> would be like zone1970.tab except with the cutoff being now, i.e., it would
> partition the world into regions where civil-time clocks agree from now
> into the predicted future (but may disagree in the past). A server that
> wants to cater only to current and future timestamps could limit itself to
> zones in zonenow.tab.

Good idea.  In a more general sense, this reminds me somewhat of the
"winnow" functionality discussed on tz briefly in 2013
<http://mm.icann.org/pipermail/tz/2013-September/thread.html#19741>.
Properly implementing that for tz would possibly require a bit of a
re-architecting on that project. (e.g., How do we indicate which of the
America/Indiana/* zones is the main one if we winnow from, say, 2000?)

Perhaps that's ultimately worthwhile, but I'm not sure where that ranks on
the priority queue of all the possible things tz could be implementing,
especially those which would require some re-architecting anyway...

--
Tim Parenti

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 28 Oct 2015 14:35:12 -0400

Hi Eliot,

> And then we have to return to whether or not this is appropriate given

To be honest with you I don't have a serious use case to implement this 
right now.

So if we drop that suggestion, that just leaves two possible things for the 
WG:

1) Registering a zoneinfo media type (which I think can be done without the 
need for a WG).
2) Something new to think about: should we propose that IANA run a tzdist 
service as another facet of the time zone database support they do? That 
would certainly be a way to "bootstrap" interest in the protocol.

-- 
Cyrus Daboo

---

From: Eliot Lear <[email-masked]>
Date: Thu, 29 Oct 2015 10:53:40 +0200

<chair hat on>

On 10/28/15 8:35 PM, Cyrus Daboo wrote:

> To be honest with you I don't have a serious use case to implement
> this right now.

ok.

>
> So if we drop that suggestion, that just leaves two possible things
> for the WG:
>
> 1) Registering a zoneinfo media type (which I think can be done
> without the need for a WG).

Do others agree or disagree?

> 2) Something new to think about: should we propose that IANA run a
> tzdist service as another facet of the time zone database support they
> do? That would certainly be a way to "bootstrap" interest in the
> protocol.

The same sorts of questions:

1.  Would the community make use of such a service?  I think when it
comes to a continuing operational cost, there would have to be very
strong and broad demand.
2.  Is it appropriate for IANA to perform this function?  This one would
require discussion once we get past (1).
3.  Is there a draft author?   Never too early to write a draft to
define the service requirements and how it would be managed.  It's not
all protocol.
4.  Are there reviewers?

Eliot

---

From: Ken Murchison <[email-masked]>
Date: Thu, 29 Oct 2015 08:06:35 -0400

> Do others agree or disagree?

I agree that its worth registering a zoneinfo/tzdata/tzfile (or 
whatever) media type.  I don't know if this can/should be done outside 
of a WG.  I'll leave that for the chairs/ADs to decide. Having just 
written an iCalendar -> tzfile(5) translator, I'd be willing to help 
write a draft, but would defer to Paul on this.

> define the service requirements and how it would be managed.  It's not

I would think that admins and OS vendors would love to have "real-time" 
updates of tzdata rather than having to download, compile, and 
distribute that data themselves.  If the community were to switch to 
using tzdist for tzdata distribution, IANA seems to be an appropriate 
primary provider.  I'd be willing to contribute to and/or review a draft 
of the service requirements.

---

From: Doug Royer <[email-masked]>
Date: Thu, 29 Oct 2015 10:22:23 -0600

> comes to a continuing operational cost, there would have to be very

Most users would not have a clue it happened and would still complain if
they did not get their TZ updates.

There are already some systems in place for this kind of thing.

Has anyone contacted NTP.org or NIST?
(http://www.nist.gov/pml/div688/grp40/its.cfm)

> require discussion once we get past (1).

They are fantastic as a registration service. Do they run any other kind
of data servers? I can't think of anything like this now.

For the most part IANA does not review changes to content, they depend
on the IETF process to inform them of changes.

I think this would be a large change in mission for them.

--

---

From: t.petch <[email-masked]>
Date: Fri, 30 Oct 2015 15:28:39 +0000

Doug

IANA have long been a source for MIB Modules and registries arising
therefrom, with the first version appearing in an RFC with the rules for
updating, and then subsequent updates being done by whatever is
sufficient.

RFC3877 set up such a registry for ItuProbableCause.

Tom Petch