bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: XML-like date/time support ?


From: Nicolas Mailhot
Subject: Re: XML-like date/time support ?
Date: Mon, 09 Jan 2006 01:56:24 +0100

Le dimanche 08 janvier 2006 à 16:24 -0800, Paul Eggert a écrit :
> Nicolas Mailhot <address@hidden> writes:
> 
> > The XML folks have defined a single common international date/time
> > format
> 
> I just looked at <http://www.w3.org/TR/NOTE-datetime> and it appears that
> 
> (1) There are 9 formats, not 1.

Ok, I admit there are some variations. Didn't want to scare you at
first ;)

> (2) There is no way to represent a leap second.  This is not normally
>     a problem, since few coreutils hosts handle leap seconds
>     correctly, but for those hosts that do I suppose we can just
>     ignore the XML standard.
> 
> (3) There is no way to represent time zone offsets that are not a
>     multiple of a minute, or years before 0000 or after 9999, or a few
>     other things like that.  But I suppose they are just inheriting
>     these limitations from ISO 8601.

All these are probably inherited from ISO 8601. As one of my colleagues
said "when we won't loose hours anymore at DST we'll worry about the
leap seconds"

Even the minute TZ part is conservative - no one is mad enough to
specify an official TZ nowadays which wouldn't be a multiple of an hour
(forgetting about leap seconds for now)

> I suppose we can add an option for this, with an operand to specify
> which of the 9 formats you want.  Something like the existing "date
> --rfc-3339=TIMESPEC".
> 
> But I'm a bit leery of calling it "date --xml=TIMESPEC", or "date
> --w3c=TIMESPEC".  These guys might change their mind some day in the
> future.  Is there some more-specific name we can use, that XML folks
> would recognize?

You can use w3c-datetime or xml-datetime. There is only one official
datetime format in XML, it's the one Reuters submitted. Sometimes it's
called ISO 8601 time but that's abusive - it's really the W3C profile of
the ISO 8601 spec.

> Also, I see a slightly different set of rules in
> <http://www.w3.org/TR/xmlschema-2/> (2004-10-28), section 3.2.7.  For
> example, it says that a canonical representation cannot use the time
> zone "+00:00", and that fractional seconds cannot end in "0", and that
> the time zone is optional.  What gives?  This document looks far more
> official: does it supersede the document you mentioned?  Should "date"
> output a canonical representation?

Yep, the xml schema is the official specification from hell everyone
wants to forget (too long, too convoluted). Everyone hates w3c schema -
it'll get superseded by something more sane like relax NG in time. But
the basic data types will stay the same and datetime is one of them.
It's only formalising the Reuters doc BTW.

1. you can not use +00:00 -> W3C marks the UTC timezone as Z not as
+-00:00 (I wrote this in my last message I think). You'll find the same
rule in the Reuters doc

2. the time zone is optional because XML is a wide standard so it needs
to take into account stupid OS's that still only know local time. But a
datetime without timezone is useless in practical terms, so any org that
cares about time will make the TZ mandatory in its XML schemas (XML
allows you to me more strict than the general spec) 

3. I forgot the fractional seconds part. Probably means you're not
allowed to pad with zeros. I don't think it's enforced in real life (but
I may be wrong)

> I guess that might mean that there are 10 XML formats instead of 9?

There are two main formats : local time with UTC offset and UTC time
("Zulu time")

The rest are just variations on the precision level you want.

It's probably OK to just output YYYY-MM-DDThh:mm:ssTZD as this is the
format most people will need. But if you want to code the other
variations, more power to you.

> Or even more, if non-canonical formats are desired? 

Non canonical formats are not desired at all. XML is stop on first
mistake - canonical is the only thing allowed.

Regards,

-- 
Nicolas Mailhot

Attachment: signature.asc
Description: Ceci est une partie de message numériquement signée


reply via email to

[Prev in Thread] Current Thread [Next in Thread]