tz SOAP service?

[e2]

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 at CS.UCLA.EDU] 
Sent: February 24, 2006 1:28 PM
To: e2 at sympatico.ca
Cc: tz at elsie.nci.nih.gov
Subject: Re: tz SOAP service?

> From: e2 [mailto:e2 at 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.