Re: is YYYY-MM-DD HH:MM:SS an ISO8601 format?

2006-11-15 Thread Zefram
David Cantrell wrote:
>Isn't the timezone also required?

No.  Particular applications of ISO 8601 may require it, but ISO 8601
itself does not.  The standard allows great freedom in the choice
of elements, and concerns itself with how to represent the desired
combination of elements.  Mechanism, not policy.

-zefram


Re: is YYYY-MM-DD HH:MM:SS an ISO8601 format?

2006-11-15 Thread David Cantrell

Zefram wrote:


Your analysis is correct.  Default ISO 8601 rules require date
and time-of-day portions to be separated by a "T" or "t".  So
"2006-11-15T11:04:40" and "20061115t110440" are valid.


Isn't the timezone also required?

--
David Cantrell


Re: is YYYY-MM-DD HH:MM:SS an ISO8601 format?

2006-11-15 Thread Zefram
Joshua Hoblitt wrote:
>Thoughts or comments on this bug that was just filed on DT::F::ISO8601
>would be appreciated.  The summary: "-MM-DD HH:MM:SS" is not accept
>by DT::F::ISO8601 and I don't believe it's a valid 8601 format.

Your analysis is correct.  Default ISO 8601 rules require date
and time-of-day portions to be separated by a "T" or "t".  So
"2006-11-15T11:04:40" and "20061115t110440" are valid.  Only by prior
agreement may the separator be omitted.

The "prior agreement" expression means that it's not standard, and
formally has the status of any other non-standard variation that one
might invent.  Leaving out the separator is technically as non-conforming
as putting the time-of-day portion first.  However, the standard committee
is suggesting that omitting the separator is a particularly reasonable
variation.  When the need (a tight space constraint) exists, this is
the approved way to adapt the rules.  The same expression is used for
variations such as five-digit years, to address other situations that
the basic standard doesn't cover.

Omitting the separator is presumably meant to allow the format
"20061115110440", not "2006-11-1511:04:40".  The latter would be silly,
saving a character in one place at the expense of conformance while
retaining other unnecessary separators.

The common practice of replacing the "T" with a space isn't mentioned in
the standard at all, AFAIR.  This is presumably because it is a gratuitous
variation: it doesn't save space or satisfy any other syntactic or
semantic requirement.  It also breaks the consistent feature that ISO
8601 formats consist only of printing characters, never spaces.  It is
commonly done simply for human familiarity, to more closely resemble
pre-standard date conventions.  I think applications that want to use
such non-standard variations can do their own conversions.

Interesting comparison: MySQL allows *any* non-digit character for the
"T" separator, and indeed for all the other separators.  It can do this
because it requires a particular sequence of elements: four-digit year,
month, day of month, hour, minute, second.  Any application that needs
to accept different element sequences needs to look at the prefix and
separators.

-zefram


Re: is YYYY-MM-DD HH:MM:SS an ISO8601 format?

2006-11-15 Thread David Cantrell

Joshua Hoblitt wrote:

Thoughts or comments on this bug that was just filed on DT::F::ISO8601
would be appreciated.  The summary: "-MM-DD HH:MM:SS" is not accept
by DT::F::ISO8601 and I don't believe it's a valid 8601 format.


Indeed, I believe it should be (eg) 2006-11-15T10:58:55Z or similar.

--
David Cantrell


is YYYY-MM-DD HH:MM:SS an ISO8601 format?

2006-11-15 Thread Joshua Hoblitt
Thoughts or comments on this bug that was just filed on DT::F::ISO8601
would be appreciated.  The summary: "-MM-DD HH:MM:SS" is not accept
by DT::F::ISO8601 and I don't believe it's a valid 8601 format.

http://rt.cpan.org//Ticket/Display.html?id=23307

-J

--


pgpzupHphCe99.pgp
Description: PGP signature