Subject: Re: [xsl] Timezone concept broken in XPath 2.0?|
From: Michael Ludwig <mlu@xxxxxxxxxxxxx>
Date: Fri, 07 Nov 2008 16:22:27 +0100
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.
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?
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...
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), 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.
|<- Previous||Index||Next ->|
|Re: [xsl] Timezone concept broken i, Deborah Pickett||Thread||Re: [xsl] Timezone concept broken i, Jim Melton|
|[xsl] Re: Complex merge of two docu, Mark Peters||Date||Re: [xsl] Group by Element based on, Friend, Darris E|