Emmanuel Eriksson is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: e2 [mailto:e2@sympatico.ca] Sent: Thursday, February 23, 2006 11:22 AM To: Olson, Arthur David (NIH/NCI) [E] Subject: tz SOAP service? I was going to send the following email to your tz list but thought I'd better send it just to you first. What do you think? Emmanuel Eriksson ==================== I've looked and cannot find a web service (e.g. SOAP) for providing local time conversion using Arthur Olsen's up-to-date timezone/daylight savings data. I gather that most people subscribed to this list are integrating tz into unix/linux distributions but I am wondering if there is also interest in having access to a web service. How many of you would be interested in such a thing? I'm toying with the idea of developing it. -----Original Message----- From: Olson, Arthur David (NIH/NCI) [E] [mailto:olsona@dc37a.nci.nih.gov] Sent: February 23, 2006 11:28 AM To: e2@sympatico.ca Subject: RE: tz SOAP service? You might want to take a look at... http://www.twinsun.com/tz/tz-link.htm ...to see what's already available on the Web. --ado -----Original Message----- From: e2 [mailto:e2@sympatico.ca] Sent: Thursday, February 23, 2006 11:35 AM To: Olson, Arthur David (NIH/NCI) [E] Subject: RE: tz SOAP service? Thanks. Yes, I already checked that list. The closest I found was worldtimeserver.com who have a database subscription service (I don't know if they use your data or not). They don't offer a web service - just periodic updates to the data files that are mailed to subscribers. I've asked them if they are planning to do a web service and am waiting for a reply. I'm contemplating writing one myself (I hope I'm not getting into something that I can't handle!) and was interested in whether others were interested in using it and/or contributing to the effort. Emmanuel
From: e2 [mailto:e2@sympatico.ca] Sent: Thursday, February 23, 2006 11:22 AM
I've looked and cannot find a web service (e.g. SOAP) for providing local time conversion using Arthur Olsen's up-to-date timezone/daylight savings data.
I don't know of anything specific to SOAP, no. For at least five years the XML guys have attempted to redo the iCal format in XML, which sort of sounds like what you're interested in. See <ftp://ftp.rfc-editor.org/internet-drafts/draft-royer-calsch-xcal-03.txt> for their latest attempt. So far, those attempts have not succeeded: the calendaring guys continue to prefer straight iCal. We tz maintainers have stuck with Arthur David Olson's circa-1986 text format, under the "why fix what ain't broken?" theory. If all the iCal/SOAP/XML/whatever guys got their act together and defined a common format that in practice worked better than the traditional one, I'd be all ears. So far, though, that hasn't happened. I have asked for better-than-Olson-format features (e.g., enough primitives to support standard time in the Netherlands from 1835 to 1937), but without success; this is not a good sign. You might want to be aware of the Calendar Access Protocal (CAP) described in Internet RFC 4323 <http://www.ietf.org/rfc/rfc4324.txt> (December 2005). It describes a protocol whereby a client can get up-to-date data in VTIMEZONE format. This protocol is still experimental, but its authors expect it to evolve into something that's actually supported by vendors. My guess is that they're aiming to drop support for time zone data via CAP, substituting FTP to acquire time zone data in iCal format. See <ftp://ftp.rfc-editor.org/internet-drafts/draft-royer-timezone-registry-03.txt>. I don't know how well that's progressing, though.
Thanks for the info Paul. Indeed, I'm not looking to convert Olsen data into a new format. I am just interested in developing a web service that exposes a handful of common time conversion functions. The backend would continue to use a data store using Olsen-formatted tz data. In my case, the web service will be implemented in .NET and having looked at the Olsen data I can see that parsing it will take a bit of time (to understand the format) so I was hoping to recruit some people who might have the same need for a web service to share the work. Emmanuel -----Original Message----- From: Paul Eggert [mailto:eggert@CS.UCLA.EDU] Sent: February 24, 2006 1:28 PM To: e2@sympatico.ca Cc: tz@elsie.nci.nih.gov Subject: Re: tz SOAP service?
From: e2 [mailto:e2@sympatico.ca] Sent: Thursday, February 23, 2006 11:22 AM
I've looked and cannot find a web service (e.g. SOAP) for providing local time conversion using Arthur Olsen's up-to-date timezone/daylight savings data.
I don't know of anything specific to SOAP, no. For at least five years the XML guys have attempted to redo the iCal format in XML, which sort of sounds like what you're interested in. See <ftp://ftp.rfc-editor.org/internet-drafts/draft-royer-calsch-xcal-03.txt> for their latest attempt. So far, those attempts have not succeeded: the calendaring guys continue to prefer straight iCal. We tz maintainers have stuck with Arthur David Olson's circa-1986 text format, under the "why fix what ain't broken?" theory. If all the iCal/SOAP/XML/whatever guys got their act together and defined a common format that in practice worked better than the traditional one, I'd be all ears. So far, though, that hasn't happened. I have asked for better-than-Olson-format features (e.g., enough primitives to support standard time in the Netherlands from 1835 to 1937), but without success; this is not a good sign. You might want to be aware of the Calendar Access Protocal (CAP) described in Internet RFC 4323 <http://www.ietf.org/rfc/rfc4324.txt> (December 2005). It describes a protocol whereby a client can get up-to-date data in VTIMEZONE format. This protocol is still experimental, but its authors expect it to evolve into something that's actually supported by vendors. My guess is that they're aiming to drop support for time zone data via CAP, substituting FTP to acquire time zone data in iCal format. See <ftp://ftp.rfc-editor.org/internet-drafts/draft-royer-timezone-registry-03.t xt>. I don't know how well that's progressing, though.
participants (3)
-
e2 -
Olson, Arthur David (NIH/NCI) [E] -
Paul Eggert