Project

Profile

Help

Forums » Help »

DST problem

Added by Anonymous about 17 years ago

Legacy ID: #4243830 Legacy Poster: Peter (parbho)

Hi, I have following code snippet which was working perfectly in Feb, but is broken in Apr. <xsl:template name="timestamp"> <xsl:param name="millis" /> <xsl:variable name="dt" select='dateTime(xs:date("1970-01-01Z"),xs:time("00:00:00")) + xs:integer($millis) * xs:dayTimeDuration("PT0.001S")' /> <xsl:value-of select='format-dateTime(adjust-dateTime-to-timezone($dt), "[FNn,-3] [MNn,-3] [D01] [H01]:[m01]:[s01] [ZN] [Y0001]")' /> </xsl:template> Basically the template takes time in millis (since Jan 1, 1970), and displays it in Unix style date format. My JBoss server is running in EST. In Feb, it was working great: Mon Feb 05 11:15:00 EST 2007 Now it's broken Wed Apr 04 11:15:00 AST 2007 Although the GMT has stayed the same, EST has moved forward by an hour since DST. I think Saxon is failing to take this into account. If I debug Saxon, it gets current-timezone as -PT4H and so it thinks the timezone is AST (which is Atlantic Time Zone, an hour ahead of EST). What's the best way to overcome this problem?


Replies (1)

RE: DST problem - Added by Anonymous about 17 years ago

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

I'm afraid the [ZN] facility in format-dateTime() is rather a nonsense, because there is no information available in the data value to tell you what the "time zone name" is. There is only a "time zone displacement" for example -04:00, and without knowing what part of the world you are in and whether it's summer (or what the local politicians have deemed to be summer in any particular year) there is no way of getting a reliable time zone name. Because it's in the spec (despite my best efforts to get it out) Saxon does something, but it's only a guess. The guess is driven from the country, either supplied as an argument to format-dateTime or taken from the Java locale, with a rather inadequate table of the most common timezones found in North America, Europe, and Australia. There's no attempt to automatically detect summer time boundaries, but you can if you really want supply the country parameter as "us*" to indicate that it's the US in summer. Sorry that's inadequate, but the fault is really in the design of the xs:dateTime data type which does not have any information about civil timezones.

    (1-1/1)

    Please register to reply