Re: Standards checkers for XSLT

I don't mean to contradict and there might be valid reasons in your application for using the short-hand date format YYYY-MM-DD instead of CCYY-MM-DDTHH:MM:SS+Z but, there are a few more advantages of using the composite date format that also includes
time instead of just the date.

For example, it's more straightforward to calculate the *duration* between two dateTimes when the dates are represented in full format.

The time-zone is optional, so if you represent it as CCYY-MM-DDTHH:MM:SS it assumes the implicit time-zone of the server combined with daylight savings.

I think if your application is going to be complex with many possible scenarios then I would consider using the full format, but if your application tends to be small and doesn't deal with event math or dateTimes then the shorter version of dateTime seems fine.

But thinking in terms of making the application as change-proof and future-proof as possible (to be able to easily handle all possible future situations with as little or no change to the original design) , I would use the full date format.

In either case there are functions in XPath2.0 which allow you to combine dates or break them up in any way, which makes it flexible to use any date format.

----- Original Message ----
From: Kamal Bhatt <kbhatt@xxxxxxxxx>
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Sent: Sunday, November 26, 2006 7:04:16 PM
Subject: Re:  Standards checkers for XSLT

Rashmi Rubdi wrote:

Using a common and standard convention for representing dates helps significantly when manipulating date fields.

The standard format is CCYY-MM-DDTHH:MM:SS+Z

Example:
2004-10-01T18:23:17+00:00

With this representation it's easier and manageable to sort date fields because it's a sortable value unlike a date represented in say MM/DD/YYYY format.

While displaying dates the XPath2.0 format-date function can be used to display the date in a particular locale.

There might be other benefits like add and subtract dates, but I haven't refered these functions.

I think we use YYYY-MM-DD (we don't handle timezones), but thanks for the tip.

--
Kamal Bhatt