RE: [XQuery] implicit timezone

Treat the implicit timezone as a best guess. Any application that wants to
do timezone handling properly is going to have to do it explicitly.

Inferring the implicit timezone from the actual date/time gives all sorts of
problems: when the clocks are put back at the end of summer, the dateTime
values for one hour occur twice. What timezone would you infer for the
dateTimes in this interval?

And what about times with no associated date? The chances are that in a bus
timetable, the raw time "11:15" probably means 11:15 summer time in summer,
and 11:15 winter time in winter, so it is not really a time that recurs
every 24 hours at all. If this matters to you, you can't use
times-without-timezones to represent this data. This isn't the end of the
world, there are plenty of other good ways of representing it.

There's very little point in getting into more and more complexity on date
and time handling. It will never be perfect. The addition of timezones to
dates is an example of the nonsense you get when you go down this route -
someone pointed out that Christmas Day in New Zealand is not the same period
of 24 hours as Christmas Day in South Africa, which is logically true, so
you end up with all this additional machinery to solve a theoretical
problem, which no-one will ever use in practice.

Michael Kay 

> -----Original Message-----
> From: public-qt-comments-request@w3.org 
> [mailto:public-qt-comments-request@w3.org] On Behalf Of Xavier Franc
> Sent: 25 May 2004 17:40
> To: public-qt-comments@w3.org
> Subject: [XQuery] implicit timezone
> 
> 
> There is a little oddness about the implicit timezone: it seems to 
> depend only
> on the dynamic context:
> 
>  >        2.1.2 Dynamic Context
>  >
>  > [Definition: Implicit timezone. This is the timezone to be 
> used when 
> a date, time, or dateTime value that does not
>  > have a timezone is used in a comparison or in any other operation. 
> This value is an instance of
>  > xdt:dayTimeDuration that is implementation-defined.]
> 
> Typically, this implementation-defined timezone will be the 
> local timezone,
> which in many countries is not the same in winter and in summer,
> due to Daylight Saving Time.
> 
> So the expression xs:date("2004-01-01") wont
> correspond with the same UTC time if it is computed in
> winter or summer.
> 
> However, it is a bit odd to apply a summer timezone (DST)
> to a winter date ... It seems that it should depend
> on the date itself, shouldn't it ?
> 
> And actually, this is what happens for example
> with Java classes: if you parse "2004-01-01" with the appropriate
> java.text.DateFormat, you dont get the same
> difference to GMT as you get when parsing "2004-06-01".
> 
> This can be a practical issue in XQuery applications.
> 
> By the way, if somebody can explain me what is the meaning
> of a timezone applied to a DATE, s/he is welcome.
> I understand of course the meaning of a timezone
> applied to a dateTime, but would anybody say
> "Christmas 2004 CST, not to be confused with
>  Christmas 2004 GMT " ?
> 
> 
> 
>

Received on Tuesday, 25 May 2004 14:09:31 UTC