* Michael Kay <mike(_at_)saxonica(_dot_)com> [2005-09-23 06:48]:
Saxon isn't currently handling the "Z" and "z" specifiers in
format-date/time correctly. Hopefully this will be fixed at the
next release - though whether the answer will actually be what RFC
822 expects is an open question. I didn't realize RFC 822 had the
US time zone names hard-coded into it - talk about cultural bias!
It's from our defense community. Those people are supposed to
have a cultural bias. Sorry.
RFC 822 dates were designed for mail headers, and are not for
end-user consumption.
There's a bit of a problem with these as there's no way of knowing
whether a timezone of -05:00 means EST or CDT, even if you know to
use a US timezone (which one can get from the country argument).
My picture and process is correct then. Go to GMT and make GMT a
literal in the picture, because XSLT 2.0 is not able to give a
correct US timzone (and most things want GMT anyway). If there
were a further parameters, maybe a latitude and longitude, you
could also implement daylight savings, but I don't see how you
could do it otherwise.
If I wanted to be serious about it, I'd create a table to
lookup the day name and month name, since it is spec'd value in
computer readable date format, and not user readable format.
From what I see in the XSLT 2.0 specification, day names are
implementation defined. Another XSLT vendor might decide that
culturally, in the United States, Wedensday is Humpday.
Thanks.
--
Alan Gutierrez - alan(_at_)engrm(_dot_)com
- http://engrm.com/blogometer/index.html
- http://engrm.com/blogometer/rss.2.0.xml
--~------------------------------------------------------------------
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>
--~--