RE: Working with time zones and XQuery

XQuery is not DST aware.

Best regards
Michael

> -----Original Message-----
> From: public-qt-comments-request@w3.org [mailto:public-qt-comments-
> request@w3.org] On Behalf Of Bill Patton
> Sent: Friday, March 16, 2007 11:28 AM
> To: public-qt-comments@w3.org
> Subject: Working with time zones and XQuery
>
>
> Dear Sirs,
>
> I am currently working on implementing all the date/time data types in
> XQuery
> and associated F&O functions.  This has all been straight forward except
> when
> I get to time zones.  I have read the W3C technical note "Working with
> Time
> Zones", which points out the distinction between a "time zone offset" and
> a
> real "time zone" which has a historical schedule for daylight savings
> time,
> DST.  The note points out that comparing zoned with unzoned dateTimes is
> problematic.
>
> The XQuery specs and the XML Schema specs remain strangely silent about
> DST
> and, according to the the technical note, misuses the term time zone for
> time
> zone offset.
>
> I believe that there are two consistent interpretations of the spec: one
> where
> the spec describes date/time values which use standard time and no DST,
> and
> one that allows for DST by computing time zone offsets for the date and
> time in question.  The goal is to have a query where the data does not
> change
>  give the same answer when run in the summer or winter.  The
> implementation
> should also be consistent for some time zone preferably the default time
> zone
> for the computer running the query.
>
> XQuery uses the "implicit time zone" from the dynamic context to fill in
> missing information during operations involving unzoned date/times. If we
> use functions time-zone-by-utc(utc) and time-zone-by-wall(wall), which
> return
> the time zone offset for a specific dateTime, and we use these in the
> places
> where the spec calls for the implicit-timezone from the dynamic context,
> we
> get an implementation that is consistent and allows for DST.  In this
> model
> implicit-timezone() might be defined as time-zone-by-utc(current-
> dateTime()).
>
> Here are some questions I am not clear about that lead me to the
> conclusion
> that we should really be using a time zone offset function rather than a
> timezone offset constant. Please note the questions may reflect a poor
> understanding on my part.
>
> 1)  Should the XQuery implicit time zone stored in the dynamic context
>     reflect daylight savings time, DST?   Should the implicit time zone
>     for a computer on the east coast of the US change from -5:00 hours
>     in the winter to -4:00 hours in the summer, or should this variation
>     be handled in some other way?
>
> 2)  Is a dateTime without an explicit time zone supposed to represent
>     a local dateTime in the time zone of the computer running XQuery?
>
> 3)  Should the date, time, and zone offset fields returned by the
>     current-dateTime() function reflect wall clock time relative to UTC
>     time?   That is, for a computer on the east coast of the US would we
>     expect to see times like 2002-07-01T10:00:00-04Z in the summer and
>     2002-01-01T10:00:00-05Z in the winter?
>
> 4)  Should adjust-dateTime-to-timezone(current-dateTime(), ()) always
>     return the wall clock time in the computer room?
>
> 5)  Are the following identities always true for any time zone and any
>     time of the year?
>
>     timezone-from-dateTime(current-dateTime()) eq implicit-timezone()
>     adjust-dateTime-to-timezone(current-dateTime()) eq current-dateTime()
>
> 6)  We should always be able to convert from wall time to UTC and
>     back again.  Are the following examples, which adjust wall time to
>     zoned time, correct for a computer using EST time?
>
>     adjust-dateTime-to-timezone(xs:dateTime("2002-07-01T10:00:00"))
>     2002-07-01T10:00:00-04:00 : xs:dateTime
>
>     adjust-dateTime-to-timezone(xs:dateTime("2002-01-01T10:00:00"))
>     2002-01-01T10:00:00-05:00 : xs:dateTime
>
> 7)  Are the following examples, which adjust each of the results above to
>     UTC time, correct?
>
>     adj xs:dayTimeDuration("PT0S"))
>     2002-07-01T14:00:00Z : xs:dateTime
>
>     adjust-dateTime-to-timezone(xs:dateTime("2002-01-01T10:00:00-05:00"),
>         xs:dayTimeDuration("PT0S"))
>     2002-01-01T15:00:00Z : xs:dateTime
>
> 8)  Are the following examples, which adjust UTC time to local time,
> correct
>     for a computer running on EST?
>
>     adjust-dateTime-to-timezone(xs:dateTime("2002-07-01T14:00:00Z"))
>     2002-07-01T10:00:00-04:00 : xs:dateTime
>
>     adjust-dateTime-to-timezone(xs:dateTime("2002-01-01T15:00:00Z"))
>     2002-01-01T10:00:00-05:00 : xs:dateTime
>
> 9)  Are the following examples, which convert the results above to unzoned
>     time, correct?
>
>     adjust-dateTime-to-timezone(xs:dateTime("2002-07-01T10:00:00-04:00"),
> ())
>     2002-07-01T10:00:00 : xs:dateTime
>
>     adjust-dateTime-to-timezone(xs:dateTime("2002-01-01T10:00:00-05:00"),
> ())
>     2002-01-01T10:00:00 : xs:dateTime
>
> 10) When comparing dateTimes without a time zone offset, should we, in
>     effect,  historically correct them to UTC, taking into account the
> zone
>     offset for that particular date and time?  If the implicit time zone
>     changes from summer to winter, some XQuery computations will produce
>     different results when run in the summer rather than in the winter,
>     even when the data itself has not changed.  Applying the historical
>     time zone offset corrections eliminates this problem, since it ties
>     zone offsets to the data rather than the implicit time zone. An
>     implementation might achieve this type of comparison by simply using
>     the long utc millisecond times corresponding to dateTime values for
>     comparison operations.
>
>     Using a correction such as this changes the result of XQTS
>     K-DatesSubtract-1 which is,
>
>     xs:date("1999-07-19") - xs:date("1969-11-30") eq
>         xs:dayTimeDuration("P10823D")
>
>     from true to false for a computer running on EST time.  This
>     is because xs:date("1999-07-19") - xs:date("1969-11-30") is
>     P10822DT23H.  One hour is lost in April when the clock is set ahead
>     to DST.  None of the other XQTS tests seem to be affected.
>
> 11) What does the XQuery spec mean when it says in section 10.2 "Before
>     comparing or subtracting xs:dateTime values, this local value must
>     be translated or normalized to UTC"?  Does it mean we should make
>     historical time zone correction?  It is my understanding that making
>     historical corrections only makes sense when all the data originates
>     in the same local time zone as the computer running the query.
>
> 12) During the spring when the local time suddenly jumps ahead there is
>     a one-hour hole in the time continuum between 2 AM and 3 AM EST where
>     2:30 AM is forbidden.  Even worse, in the fall when the time jumps
>     from 2:00 AM to 1:00 AM there is a one-hour period where times occur
>     twice in a day, so there are two 1:30 AM's.  I will refer to this
>     period as the "Twilight Zone". In order to convert 1:30 AM to UTC
>     during the twilight zone you need to know which 1:30 you are talking
>     about - the 1:30 EDT or the 1:30 EST which occurs one hour later.
>     The local time, of course, doesn't have an extra bit to express which
>     1:30 AM it represents, so which one should we pick?
>
> 13) If you naively use the Java GregorianCalendar class to compute the
>     number of days elapsed since 1 AD, you will be off by 2 days from the
>     XML Schema algorithm for adding a duration to a dateTime.  Setting
>     the Gregorian/Julian cutover to the smallest negative integer
>     produces the correct answer.  Does this mean that the XQuery dateTime
>     is based purely on a Gregorian calendar, which is sometimes called
>     the "Proleptic Gregorian Calendar"?  Using XQuery to do dateTime
>     arithmetic spanning 1582 will give results different from the dates
>     recorded in history books, which are based on the Julian calendar
>     for dates before 1582.
>
> 14) What implementation-specific query context options and settings are
>     needed to make dateTimes really useful?
>
> What I find perplexing about all this is that I can calculate times from
> 9999
> BC to 9999 AD with 1 millisecond accuracy knowing only the 4yr, 100yr,
> 400yr
> rule for leap year and get the same answers as the Java GregorianCalendar,
> but
> I don't know how to get simple wall clock times out of XQuery.  Wall clock
> time is ubiquitous; most of us carry it strapped to our wrists.
>
> Please let me know if you have any answers.
>
> Bill Patton
> http://www.cogneticsystems.com

Received on Friday, 16 March 2007 20:01:54 UTC