Tossing a wacky idea into the ring...
Why not read the semantics for T as time since 0..
2011-01-17 is day precision
2011-01-17T01 is hour precision and means 1 AM
2011-01-17T01:02 is minute precision and means 1:02 AM
This all agreed.. with this reading of T we get the T:24:00 and
T12:60 paradigm extended to arbitary hours, minutes..
2011-01-17T25 would be hour precision and 1 AM on the 18th
basically I am thinking of allowing for simple math... this could
be interesting for dumb clients.
A process, for example, might return a date-time and a client wants
to specify a date-time 6 hours and 12 minutes later.. with this model
the clients do not need to know the calendar (how many days in the
month etc.).. We would specify a normative (max. 23 hours and 59 min)
but have multiple semantically equivalent representations for any
given date-time assertion.
Parsing and normalization is easy enough ..
On Tue, 18 Jan 2011 14:56:52 -0500, Ray Denenberg, Library of Congress wrote
> From: C. M. Sperberg-McQueen
> > Sent: Tuesday, January 18, 2011 12:38 PM
> > On this topic, it may be worth mentioning that contrary to what I
> > believe the EDTF spec says, the form "24:00:00" is defined and legal in
> > the relevant XSD datatypes; the lexical forms '2011-01-17T24:00:00' and
> > '2011-01-18T00:00:00' have the same value.
> Yes, the spec does imply that these are not valid in xs:dateTime,
> and you're right, they are valid (I just now tested them).
> This changes my view on the matter, I cannot see a justification to profile
> these out. In fact, if the xsd data types are cited as "profiled
> in" I don't even think these need to be cited as special cases.
> Thanks, Michael.
Edward C. Zimmermann, NONMONOTONIC LAB
Basis Systeme netzwerk, Munich Ges. des buergerl. Rechts