Saxon

Legacy ID: #10314572 Legacy Poster: Michael Kay (mhkay)

This is really a question about the specs, not about Saxon. I think you will find that Saxon does what the specs say. Essentially, the dateTime data types understand time offsets, but not timezones. (They talk about timezones, but it's a misnomer). If you have a dateTime with an explicit time offset, then arithmetic operations will result in another dateTime with the same offset. If you use a dateTime with no time offset, then the implicit offset is based on the difference between your wall clock and GMT at the time you run the query. To help you get around these problems, Saxon provides the function saxon:adjust-to-civil-time() http://www.saxonica.com/documentation/extensions/functions/adjusttociviltime.xml If you apply this function to the result of your time computation, specifying "Europe/Brussels" as the time zone name, you should get what you consider the "intuitive" answer.

Legacy ID: #10316746 Legacy Poster: Nick Van den Bleeken (nvdbleek42)

Thank you for the fast reply and sorry fo posting it to the wrong forum/list. I understand that xs:dateTime doesn't supports 'time zones' but only offsets to UTC. Also saxon:adjust-to-civil-time() helps me in determining the UTC offset in a particular timezone at a particular date. But as I see it it doesn't helps much when doing calculations (I could extract the offset component of both dates and compensate based on the difference, but this feels like a hack). I also realize that that if fn:adjust-dateTime-to-timezone() will use time zone information instead of current UTC offset this will only solve my 'problem' when offset component is provided in the xs:dateTime. But if it would work like this it at least solves the local time part of the 'problem'. As a side note XForms also has a version adjust-dateTime-to-timezone() (in the next version all xforms extension functions will be in the xforms NS) and for that function we recently decided to issue an erratum that adjust-dateTime-to-timezone() should take into account local time zone information and not local UTC offset at this moment. Do you think that it is worth sending a message to the XSL mailing list explaining the problem with dateTime calculation in combination with DST? Thanks in Advance, Nick Van den Bleeken

Legacy ID: #10316998 Legacy Poster: Michael Kay (mhkay)

I think you should probably take this up with the XSL/XQuery WGs. It's a known problem, though I'm not sure there is a will to solve it. Many of us went through the period when we were debating whether 29 Feb 2004 plus one year is 28 Feb 2005 or 1 Mar 2005, and know that we will never get an answer that everyone agrees on; handling civil time zones can only multiply such problems, and many would argue that this should be in an application-level function library.