[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Timezone concept broken in XPath 2.0?

Subject: Re: Timezone concept broken in XPath 2.0?
From: Jim Melton <jim.melton@xxxxxxx>
Date: Fri, 07 Nov 2008 09:59:04 -0700
Re:  Timezone concept broken in XPath 2.0?
At 11/7/2008 08:22 AM, Michael Ludwig wrote:
Deborah Pickett schrieb:
Michael Ludwig wrote:
Why aren't the functions specified to use a timezone database and
then work like timezone-aware localtime() in Perl and C?

At a guess, I'd wager that it's the sheer complexity of maintaining a timezone database that can never be completely future-proofed.

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. 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. Bang...no need to ask the UN, notify the Astronomical Union, or anything else. Just say it's so.



Imagine if every implementation of XSLT 2.0, including embedded ones,
had to grok timezones all around the world.

They can leave the grokking up to the OS. Already, XSLT relies on the OS feature called "system time" when reading the time and the offset from UTC. Why stop half-way and not take into account the concept of the timezone, which is offered for free, like date and time?

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.,


I may be mistaken, of course, but systems without these fundamental
features are maybe not the hottest candidates for hosting XSLT
processors anyway.

Then imagine when $government decides to change the rules for $region
next year...

System update. Due anyway. XSLT won't have to bother.


I agree that the XPath zone-conversion functions that you mention are
limited, and arguably misnamed, but they do have a use: the functions
in XPath 2.0 are enough for you to implement your own zoneinfo
database, or even to parse the Olson database file format.  It's
possible to code a pure userland XSLT 2.0 implementation of zoneinfo,
but XSLT implementations which have no need for it don't have to carry
the baggage.

That's an interesting proposition. 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 ;^)


, I'd have to use my own timezone extension
functions as well: It would probably be difficult to convince the
built-in functions to tap into my home-grown database.

Oh, I see: I could probably use them to build my own functions which tap
into my own database. That would probably work. But then, of course, I'd
rather ask Java, or Perl, to do the timezone handling.

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.


Hope this helps,
   Jim


Michael Ludwig

========================================================================
Jim Melton --- Editor of ISO/IEC 9075-* (SQL) Phone: +1.801.942.0144
Chair, W3C XML Query WG; XQX (etc.) editor Fax : +1.801.942.3345
Oracle Corporation Oracle Email: jim dot melton at oracle dot com
1930 Viscounti Drive Standards email: jim dot melton at acm dot org
Sandy, UT 84093-1063 USA Personal email: jim at melton dot name
========================================================================
= Facts are facts. But any opinions expressed are the opinions =
= only of myself and may or may not reflect the opinions of anybody =
= else with whom I may or may not have discussed the issues at hand. =
========================================================================


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.