[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: Michael Ludwig <milu71@xxxxxx>
Date: Mon, 10 Nov 2008 13:11:30 +0100
Re:  Timezone concept broken in XPath 2.0?
Michael Kay schrieb am 10.11.2008 um 11:01:30 (-0000):
> > 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.
> 
> There are a zillion features that aren't supported in the XPath
> function library. After all, it only contains a little over 100
> functions: by way of comparison, the Java class library contains over
> 3700 classes, and heaven-knows how many methods. So the fact that the
> function you want is not present is not something one can regard as a
> bug. 

That's not what I said might be regarded as a bug, or an oddity. Rather,
I was referring to the behaviour of three functions that *are* present.

The functionality I want can easily be pulled in thanks to the extension
mechanism. (I'm doing this in 1.0 with LibXSLT, Perl and Pretty Home
Page, it's no problem at all.)

> The fact that civil timezones aren't supported is largely because they
> aren't supported in XML Schema, which in turn is because they aren't
> supported in ISO 8601. 

Aha, I see.

> Although it's true that many applications have to cope with civil time
> displacements, it's equally true that many applications have to cope
> with changing tax rates and exchange rates. Would you expect a generic
> function library to know about such things? I think there is something
> in the argument that this kind of thing belongs more in the
> application layer than the technology layer. 

That may be so - I'm not knowledgeable enough to know this. I was just
used to programming environments offering civil timezone functionality.
I can add this to XSLT and XQuery using extensions, so that's fine.

> There are many practical difficulties. How would we specify the result
> of such functions (by reference to the Olson database, or by reference
> to the decisions of national governments?)

The results could be specified as they are now. Their correctness with
regard to civil timezones would not be specified at all. This would
depend on the timezone database used by the implementation, just as the
correctness of the time given by current-dateTime() depends on the
system clock.

> How far into the past and the future would we expect an implementation
> to have information about civil time zone displacements?

Good question. How do others do it? An XQuery implementation built into
a database system would probably be expected to tick like the database
system. This is clearly implementation-defined.

> Would we require the information to be available for the whole world,
> or only those parts of the world that a particular vendor is
> interested in?

Implementation-defined. Even Kiribati is in the database, so the
coverage seems to be pretty good ...

> Would we need to have conformance rules requiring an implementation to
> be updated within N days of a legislative change (or a change to the
> Olson database?)

No. An implementation would be free, of course, to subdue itself to
ultra-strict conformance rules, if it wants to. The W3C, on the other
hand, doesn't require the system clock to be set accurately either, so
why should it require the timezone database to be accurate? Garbage in,
garbage out, as they say.

> What happens when there is disputed authority, e.g. as in Tibet?

Is it disputed? Clearly, this wouldn't matter, as long as it doesn't
propagate to timezone database you're using.

Thank you and the other people who answered to this boring question of
mine. I've learnt about the reasons for what I think is an oddity (blame
it on my DPH background), and I know what to do in case I need civil
timezone functionality. I can, of course, live with the situation and am
not planning any proverbial bus accidents.

Thanks again,

Michael Ludwig

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.