[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Timezone concept broken in XPath 2.0?
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.
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|