[DAS] Re: das/2 proposal status

[Andrew Dalke]

Lincoln:
> What is the final decision on this?  Will it be compatible with the
> HTTP style, which is
>
> 	Fri, 08 Oct 2004 15:37:46 GMT

The ISO style for this is
    2004-10-08T15:37:46Z
or
    2004-10-08T15:37:46+00:00

It is not compatible with the HTTP style.  I'm sympathetic with
the idea now that ISO dates are more appropriate for XML documents
and HTTP dates are more appropriate for HTTP headers.

While the ISO spec is proprietary, costs money, and complicated,
it has a minimal basic requirement which is of the form

    YYYY-MM-DDTHH:MM:SS(.ss*)?(Z|[+-]hh:mm)?
where
   YYYY is the 4 digit year, MM the two digit month (01 to 12), DD
the two digit day, 'T' is the required separator between date
and time.  HH is the 24 hour time (00 to 24), MM the minute (00 to
59) SS the second (00 to 60), .ss* the optional decimal seconds,
'Z' means UTC/GMT and +hh:mm / -hh:mm the timezone shift.

Some caveats.  The XML Schema dates are different than the ISO
dates.  ISO allows 0000 to 9999 in the years while XSD doesn't
allow 0000.  ISO allows "24:00" as a time" while XSD does not.
SS = 60 only happens with leap seconds.


Python's datetime doesn't support leap seconds nor the year 0000.
Perl's default uses seconds in epoch, so doesn't go before 1970.
But DateTime.pm handles the range 0000-9999 just fine (as well as
a much larger range).  I did not look into Java but I'm pretty
sure there is standard library support for this.  I don't know
about C or C++.  There is a 'time.rb' Ruby module for XSD dates.

Were we to go this route I would say we define that all dates
be given as
    YYYY-MM-DD
all datetimes be given as
   YYYY-MM-DDTHH:MM:SS(.ss*)?(Z|[+-]hh:mm)
(timezone required, fractions of a second optional),
0001 <= YYYY <= 9999, 00<=HH<=23 and leap second support is
implementation dependent.

This is compatible with ISO 8601, compatible with XML Schema,
supportable by the likely DAS/2 clients and servers, and not
dependent on any external specification.

Because this is supported by the XML Schema definition, I
propose we use this format instead, when inside XML documents.

					Andrew
					dalke at dalkescientific.com