This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: XSLT Date
- To: XSL List <xsl-list at lists dot mulberrytech dot com>
- Subject: [xsl] Re: XSLT Date
- From: Joerg Pietschmann <joerg dot pietschmann at zkb dot ch>
- Date: Wed, 17 Oct 2001 14:54:39 +0200
- Organization: ZKB
- Reply-To: xsl-list at lists dot mulberrytech dot com
Francis Norton <francis@redrice.com> wrote
>I'd be quite happy with the functionality required for XML Schema
>(http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#dateTime, which is
>based on ISO 8601) to start with. Have you spotted any booby traps
>there?
There is not much functionality in the sense of "stuff we can invoke
from within the XSLT language to get problems solved", unless i missed
something.
It defines the lexical format for date/time related datatypes, some
rules how to interpret the values and how to add a durations and a
date and a duration. This implies that XPath can rely on robust parsing
of dates and it is cheap to define constructors, comparisions,
a simple arithmetic and perhaps additional validation routines
based on the definitions there. All this technology is proven and well
debugged.
And i have to qualify my statement above: the combination of proper
parsing, constructors/casts for the various date related types
and arithmetic is already a powerful tool. For example, you should be
able to extract the month from a date by a cast, no longer bother
to substring(.,2,4) onto a lexical format you don't control...
However, given the tendency of many users to use a localized lexical
format for dates, there is still a lot of potential for disappointment.
Regards
J.Pietschmann
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list