Re: XML Timezones

Hiya Jenny, thanks for your mail.

I think I now fully understand how the whole timezone thing works and its limitations.

> "Local time" could be resolved by the application, using whatever
> timezone information was available to it from the system.

You see its the above part that causes the problem. You see some time in UTC (as defined by the XML Schema dateTime) is not reliably resolvable to the same time. The application can certainly do the ground work (in the same way could be done for the XML Schema language type), but the actual time referred to loses context when an instance is passed around - how will the application *know* what to resolve it to (local time could be incorrect if the time was created in some other timezone).

So, basically, in the same way we have the language type which the parser i work with (MSXML 4) does no resolution (leaves it to the application really), i think there *has* to be something to represent the timezone the instance refers to and (if preferred) leave it to the application (if desired) to resolve this.

The differece is, that at least you will have some idea of what to resolve it TO - right now I have decided that the only was to make it reliable for myself is to either extend the current dateTime ot create time attribute that uniquely defines the locale.

Anyway, I don't wanna go on about this forever (being Christmas and all :), but with the advent of web services and rdf which could make extensive use of the date and time (e.g. the app i am working on just now), i feel its important to understand the potential problems we are getting into!

Anyway, Merry Christmas.

It will be here in 03:00 UTC or 00:00-03:00; just as well we don't have another in June or this time would be wrong ;)

Cheers,
Steven.
----- Original Message ----- 
From: "Jeni Tennison" <jeni@jenitennison.com>
To: <s.livingstone@btinternet.com>
Cc: <xmlschema-dev@w3.org>
Sent: Monday, December 24, 2001 11:47 AM
Subject: Re: XML Timezones


> Hi Steven,
> 
> > I was originally using the XSD dateTime data type to determine the
> > date and time to perform a task, but this is limited when applied
> > globally, because the offset (timezone) is based on local time and
> > as soon as you replicate to some other timezone, the local time
> > changes and so your scheduling information goes nuts.
> 
> I think that this idea of "local time" is what the version of dateTime
> *without* any timezone is supposed to support. So:
> 
>   2002-07-16T14:00:00
> 
> means 2pm on July 16th, 2002, local time. In Britain this would be
> equivalent to 2002-07-16T14:00:00 01:00. In France,
> 2002-07-16T14:00:00 02:00 and so on.
> 
> "Local time" could be resolved by the application, using whatever
> timezone information was available to it from the system.
> 
> However, I would only use 'local time' if I was writing about
> repeating schedules (for example train times), where you could say
> "the train departs at 2pm every day", no matter whether it's summer or
> winter.
> 
> If it's a one-off appointment, then I would use the exact time, with
> the timezone offset that was relevant at that particular time of the
> year, so Z during winter and  01:00 during summer (I think Scotland is
> the same as England here - winter is GMT and summer, BST, is  01:00).
> So since the appointment on 16th July is summer time, I'd use:
> 
>   2002-07-16T14:00:00 01:00
> 
> But beware that according to the XML Schema Datatypes Recommendation,
> there's no distinction between 2002-07-16T14:00:00 01:00 and
> 2002-07-16T15:00:00Z - applications might justifiably lose the
> timezone information from the date value, so I wouldn't rely on it.
> 
> Cheers,
> 
> Jeni
> 
> ---
> Jeni Tennison
> http://www.jenitennison.com/
>

Received on Monday, 24 December 2001 18:39:17 UTC