Re: [xsl] Timezone concept broken in XPath 2.0?

Subject: Re: [xsl] Timezone concept broken in XPath 2.0?
From: Michael Ludwig <milu71@xxxxxx>
Date: Mon, 10 Nov 2008 11:17:37 +0100
Jim Melton schrieb am 07.11.2008 um 09:59:04 (-0700):
> At 11/7/2008 08:22 AM, Michael Ludwig wrote:
> >But the OS does that. Of course it can't be completely
> >future-proofed, but sufficiently so. If some president decides to
> >move his country to another timezone, where there is more sunlight,
> >he's well-behaved enough to not make the move overnight, but announce
> >it some months in advance. And then the word spreads to OS
> >manufacturers, and OS updates work. Most of the time, at least.
> Yes, but "the OS" is an implementation, not a standard.  Saxon is an
> implementation, while XSLT 2.0 is a standard.  Standards should not
> (rightly) reference random documents that somebody has put up on the
> web, particularly when those documents are subject to (from the
> standard's viewpoint) random changes.

Maybe not. But consider that our whole world - people, trains and
everything - follows the rhythm set by local clocks. It's not something
you can opt out of. It has a certain importance, even if it is subject
to random changes.

> And please don't delude yourself into thinking that timezones cannot
> be changed, quite literally, overnight.  When the year 2000 was merely
> months away, the leader of some south Pacific nation decided that he
> wanted his country to be the first into the new millennium (well,
> actually, the first into the year prior to the new millennium, but
> that's a different argument), he invented a brand new time zone, UTC
> -14:00, and placed his country into it. need to ask the UN,
> notify the Astronomical Union, or anything else.  Just say it's so.

That's true. But does it matter in practice?

In the case of that South Pacific nation (Kiribati, or Christmas
Island), the change occurred a couple of years before 2000. The island
moved from -10:00 to +14:00, skipping New Year's day of 1995. An oddity
that is accurately reflected by zoneinfo.

    $ export TZ=Pacific/Kiritimati
    $ date --date @788954000 '+%Y-%m-%d %H:%M:%S %Z %z'
      1994-12-31 23:53:20 LINT -1000
    $ date --date @788955000 '+%Y-%m-%d %H:%M:%S %Z %z'
      1995-01-02 00:10:00 LINT +1400

First Sunrise of the New Millennium - 6. What about Kiribati?

> Implementations of XSLT 2.0 are absolutely welcome (and, IMHO,
> encouraged) to provide additional functions to handle the "names" of
> timezones around the world, using whatever source of data they like,
> whatever linguistic conventions they like, etc.  Neither XSLT nor
> XQuery limit such capabilities in any way.


> But, of course, the XSLT 2.0 Recommendation cannot say anything about
> "use this function to make your OS give you the timezone information",
> because not all OSs do it in the same way, nor do they return the data
> in the same style or format.,

How to implement timezone awareness wouldn't have to be part of the
Recommendation. UNIX, Windows, Java all provide some means to deal with
local time. As this is such a common requirement, I haven't yet
encountered a system that doesn't do local time and makes this
functionality available to applications.

> >But I guess if I implemented my own zoneinfo database (which I then
> >would have the responsibility of keeping in sync with the real world)
> Absolutely -- until you get bored, or get another job, or get run over
> by the proverbial bus ;^)


> Do it in whatever way you want, or contact the producer of your XSLT
> implementation and request an implementation-defined function (not in
> the fn: namespace, of course) to do what you want.

It's easy enough to do it yourself. The reason I posted is rather that
whether or not adjust-dateTime-to-timezone($dt) and its two fellows in
XPath 2.0 return a correct result for a given point in time $dt depends
on whether or not the offset from UTC at the time of processing matches
the offset from UTC in effect at $dt - and this strikes me as odd.


Michael Ludwig

Current Thread