xsl-list
[Top] [All Lists]

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

2008-11-10 07:12:09
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

--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--