* Michael G Schwern <[EMAIL PROTECTED]> [2007-09-02 09:32]:
> What you're thinking of is RFC3339 which is more describing a
> state of affairs on the Internet then anything else.
Actually RFC 3339 date and time formats are best practice at the
IETF/IESG.
> At best it can be *omitted* (not replaced with a space) if all
> parties agree, which we can do because we're specifying the TAP
> format. But it cannot be replaced with a space and still called
> an ISO 8601 datetime.
So specify an RFC 3339 datetime.
> Since RFC3339 isn't really a clear standard
Actually ISO 8601 gives many more options than RFC 3339, which is
why the latter was written in the first place. See 5.3 (“Rarely
Used Options”) in RFC 3339.
> it's simpler to just say that a TAP date is an
> [isodate " " isotime]. We can even say that it can also be an
> [isodatetime], but recommend the former for readability, and
> everybody wins.
You might want to look at what we did in RFC 4287:
3.3. Date Constructs
A Date construct is an element whose content MUST conform to
the "date-time" production in [RFC3339]. In addition, an
uppercase "T" character MUST be used to separate date and
time, and an uppercase "Z" character MUST be present in the
absence of a numeric time zone offset.
Such date values happen to be compatible with the following
specifications: [ISO.8601.1988], [W3C.NOTE-datetime-19980827],
and [W3C.REC-xmlschema-2-20041028].
You could pretty much adopt the same language, except for
requiring a space in place of the `T`.
The resulting date format would require a `YYYY-MM-DD` date and a
`HH:MM:SS` time in 24-hour format plus timezone offset (no
parsing TZ name strings either, numeric offsets only or a `Z` for
UTC), with optional `.nn` fractional seconds part (any number of
digits permitted).
I happen to think that datetime format is just about perfect.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
