Subject: [calsify] Fwd: New Version Notification for draft-douglass-timezone-service-01

From: Mike Douglass <[email-masked]>
Date: Thu, 03 Mar 2011 15:26:33 -0500

A new version of the timezones service draft with minor updates has been 
posted to the IETF.

Please take a look and comments are welcomed.

A new version of I-D, draft-douglass-timezone-service-01.txt has been successfully submitted by Mike Douglass and posted to the IETF repository.

Filename:	 draft-douglass-timezone-service
Revision:	 01
Title:		 Timezone Service Protocol
Creation_date:	 2011-03-03
WG ID:		 Independent Submission
Number_of_pages: 41

Abstract:
This document defines a timezone service protocol that allows
reliable, secure and fast delivery of timezone information to client
systems such as calendaring and scheduling applications or operating
systems.

The IETF Secretariat.

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

---

From: [email-masked]
Date: Fri, 4 Mar 2011 17:30:38 -0500

Am I correct that this proposal doesn't address the TZID selection problem
-- that still requires human intervention?

I wonder if LoST (RFC 5222) would be an appropriate technology to solve this
latter problem.

-- 
Jonathan lennox
[email-masked]

---

From: [email-masked]
Date: Fri, 4 Mar 2011 17:30:38 -0500

-- 
Jonathan lennox
[email-masked]

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 04 Mar 2011 22:51:15 -0500

Hi [email-masked],

> -- that still requires human intervention?

What specific problem are you interested in addressing?

> I wonder if LoST (RFC 5222) would be an appropriate technology to solve
> this latter problem.

There are web based services such as geonames.org that provide 
location->timezone mapping. It is our goal at some point to extend the 
timezone service protocol to provide support for including geographic 
region information in the timezones served up by the service - with that we 
can build a simple standard location->timezone option into the service.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 04 Mar 2011 22:51:15 -0500

-- 
Cyrus Daboo

---

From: [email-masked]
Date: Sat, 5 Mar 2011 00:24:25 -0500

> What specific problem are you interested in addressing?

Given a specific geographic location, find the TZID or VTIMEZONE that's
appropriate for that location, without requiring human intervention or
selection.

(I'm ignoring the Xinjiang problem, i.e. timezone selection based on
non-location-based considerations, for now.)

> can build a simple standard location->timezone option into the service.

LoST is designed to solve the harder problem of "given a geographic
location, find the URI of the Public Service Access Point that dispatches
police/fire/ambulence service to that location" -- harder because regions
tend to be much smaller, and because the consequences of getting things
wrong are much more serious.  So possibly it's overengineered for
location->timezone.

But specifically the feature of LoST that I thought could be useful is that
it supports defining regions based on civic addresses, which is a much more
natural fit for timezones than geospatial addresses are.

Out of curiosity, are you able to share how Apple's "Set timezone
automatically using current location" feature in Mac OS X Snow Leopard
works?  It's clearly using Core Location to get the input, but is the
mapping function hard-coded or querying something on the network?

-- 
Jonathan Lennox
[email-masked]

---

From: [email-masked]
Date: Sat, 5 Mar 2011 00:24:25 -0500

---

From: Steve Allen <[email-masked]>
Date: Mon, 14 Mar 2011 15:52:35 -0700

On Thu 2011-03-03T15:26:33 -0500, Mike Douglass hath writ:
> A new version of I-D, draft-douglass-timezone-service-01.txt has been
> successfully submitted by Mike Douglass and posted to the IETF repository.
>

I see the XML elements "utc-offset-XXX" which specify hours and
minutes.  That does not cover existing entries in the tzdata files
which have offsets of HH:MM:SS.  Although the existing such entries
are mostly historic, the results of the ITU-R actions regarding the
fate of leap seconds could make them relevant for future dates.

I think the text should allow for offsets of HH:MM:SS in order to
handle both past and possible future cases.

I also do not see how this mechanism could be used to transport the
content of the "leapseconds" file in existing distributions of tzdata.

--
Steve Allen                 <[email-masked]>                WGS-84 (GPS)
UCO/Lick Observatory--ISB   Natural Sciences II, Room 165    Lat  +36.99855
1156 High Street            Voice: +1 831 459 3046           Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m

---

From: Steve Allen <[email-masked]>
Date: Mon, 14 Mar 2011 15:52:35 -0700