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

[Deborah Pickett <debbiep-list-xsl@xxxxxxxxxx>]

Hi Michael,

Michael Ludwig wrote:
>> At 11/7/2008 08:22 AM, Michael Ludwig wrote:
>>> But the OS does that.
[...] I haven't yet
> encountered a system that doesn't do local time and makes this
> functionality available to applications.

I think that this is the root of our differing opinions.  I'd buy your
argument if we restricted ourselves to "fat" operating systems like the
general-purpose commercial or open-source ones that you name.  On such
systems, the XPath runtime can delegate time zone computations to the OS
(essentially the set of known time zone names becomes part of the
context of the expression).  The amount of work needed to be done by the
XPath processor is pretty small.

What I don't buy is the assumption that XPath is always going to run on
such "fat" platforms.  XPath is useful in embedded situations that might
have no reason to know about time zones.  Consider an SVG renderer built
into a printer.  Or a network router with its config files stored as XML
(my router does just that).  Such implementations need not even have a
real-time clock.  For them, having to implement XPath 2.0
fn:adjust-dateTime-to-timezone() is an imposition, but not a huge one.
The function is, after all, just glorified arithmetic in a weird base.

As a point of comparison, consider that XPath 2.0 doesn't provide
trigonometric or logarithmic functions, suggesting that while the
standard was being agreed upon, there was at least one lobby group that
didn't want to have to provide implementations equivalent to the
declarations in <math.h>.

I take both of these examples as application of the maxim that it's easy
to add to a standard, but damn near impossible to subtract from it.

(OT Digression: What was the first version of Windows to have full
understanding of worldwide timezones other than the one configured as
the "local" time zone?  AFAICT, Windows 3.1 doesn't, but Windows NT
does.  XPath's time zone requirements are scarily similar to Windows
3.1, come to think of it.)

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

No argument there.  They are probably not useful for end-user XPath
programmers, except perhaps in very specific circumstances.