A. Pagaltzis wrote: > * 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.
I got RC 3339 confused with RFC 2822 Section 3.3 in that post. Sorry. RFC 3339 is "most of ISO 8601 but allowing a space instead of a T" RFC 2822 is "Fri, 21 Nov 1997 09:55:06 -0600" >> 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. That's why I'm inclined to go with one based on ISO 8601 rather than just RFC 3339. More possibilities for expression. This is my inclination to go with more expressiveness than less when it comes to designing a protocol or API. If they're really not useful and just complicate matters I'm quite open to being convinced otherwise. What specifically turned me off to RFC 3339 is that all dates had to be in the current era. That works for a communications protocol where the date is describing current events (like "I sent this message at"), but not so much for a data interchange format. >> 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. What do you think of this? http://testanything.org/wiki/index.php/TAP_datetime -- Robrt: People can't win Schwern: No, but they can riot after the game.
