A. Pagaltzis wrote:
>> If they're really not useful and just complicate matters I'm
>> quite open to being convinced otherwise.
>
> OK; the goal here, I think, is to make TAP as simple as possible
> to generate as well as consume, without limiting expressiveness
> unnecessarily.
Yep, we're on the same page.
To make it clear, the use case for TAP datetimes includes both the TAP meta
information AND use in the TAP diagnostics to describe testing data. For
example, let's say you're testing some Biblical software and want to make sure
you got your dates right.
not ok 1 - age of the Earth
----
found: -05000000000-02-12
wanted: -4004-10-23
This is, admittedly, an edge case and I'm being overly conservative. If
RFC3339 is forward compatible with ISO8601 then I'm happy. We can start
simple and upgrade to ISO8601 if RFC3339 proves too restrictive.
> As far as I can see, there is no appreciable difference in the
> complexity of generating datetimes in either format.
>
> There is quite a bit of difference on the consumption end.
>
> Timezone information in RFC 3339 is numeric only. This obviates
> the need for a long mapping table in parser code, and makes a
> coarse validation of the datetime very easy – even at a human
> glance.
This is good and a restriction to ISO8601 I'd have put into the datetime spec
anyway.
> RFC 3339 also does not permit omitting the day-of-month. Only
> seconds and fractions of a second are optional, and if the
> fractions are included, seconds must also be, so the only
> optional part is always at the end of the string, before the
> timezone. Thus, datetimes with the same timezone can be sorted
> correctly with just a string compare. And accounting for the
> timezone prior to sorting isn’t hard since it’s just a numeric
> offset anyway.
Does RFC 3339 permit the following?
2007 (just the year)
2007-09 (just the year and month)
I'd like tests to be able to specify individual years and days without having
to resort to a "2007-01-01" convention. It doesn't seem like its format
allows year-date. I admit, a nit.
It also looks like we'll have to explicitly allow just full-date and just
full-time.
> The question is, do we need that flexibility? As far as I can
> tell, datetimes in TAP would almost always denote instants in
> time, not durations nor long-duration recurring events, and it
> will always be easy to come up with the current month and
> day-in-month. When timespans have to expressed, it seems to me
> they will be such that expressing them as a starting instant in
> time and an ending instant will be perfectly adequate.
I agree we can punt on timespans.
> RFC 3339 datetimes are so simple that you can write a regex off
> the top of your head and it’ll parse them correctly on the first
> try. Sorting is so easy you can write a few more lines of code
> and it too will work correctly on the first try. In contrast,
> ISO 8601 datetimes require a real parser and a date math library.
Yes, this is a worry, too.
>> 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.
>
> How? What RFC 3339 means by current era is that the year in the
> date cannot exceed 9999AD (nor go lower than 0000AD). Do you
> forsee any problems with that? Will generated TAP have to denote
> events in 10000AD or beyond, or events farther in the past than
> 0000AD?
>
> It should be noted that as far as I can tell from any ISO 8601
> docs I can find, it does not permit more than 4 digits for the
> year anyway. So the two standards don’t in fact seem to differ
> on this point.
ISO 8601:2004(E) 4.1.2.4 gives a way to expand the year representation both
beyond 9999 AD and before 0 AD
-01000000-04-20
That's April 20th, 1 million BC.
But that section has the caveat "by agreement".
--
The interface should be as clean as newly fallen snow and its behavior
as explicit as Japanese eel porn.
