Re: Re: XSLT Date

I agree about the potential for disappointment, but perhaps this is best
handled as an expectation management problem? Use this as a target
spec., and make sure potential users realise that they will have to
provide or use their own localization (of course, that's "localisation"
for my fellow Brits) routines.

For instance, C# users should probably be using
DateTimeFormatInfo.UniversalSortableDateTimePattern for timestamps in
ISO 8601 format with UTC timezones.

Francis.

Joerg Pietschmann wrote:
> 
> Francis Norton <francis@xxxxxxxxxxx> 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

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list