Re: [XQuery] implicit timezone

My goal is not to solve theoretical problems, but
practical problems, for example to produce a query
engine that both works nicely and is compliant with
W3C specifications. But if it is not possible to have
both I will definitely sacrifice the latter :)
[In fact I encountered difficulties when trying to query dates
 indexed in a database by Java code, with a XQuery expression.
 This was OK for summer dates but not for winter dates...)

Actually, since the specifications do not define
precisely what is a timezone (in particular wrt Daylight Saving Time),
there is indeed enough room for an interpretation that produces
adequate results when XQuery is used naively (ie without explicit TZ).

By the way, I still don't get what means a timezone for
xs:date or xs:yearMonth...


Michael Kay wrote:

>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 17:50:52 UTC