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 18:33:28 UTC