* Michael G Schwern <[EMAIL PROTECTED]> [2007-09-06 23:40]: > 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.
I don’t think you’re overly conservative when it comes to app data, but I agree with Ovid that this is bad separation of concerns. How dates in app data are handled should be up to the app to define. I think we should restrict this proposal solely to datetimes in TAP metainformation. (The alternative would be to push the concern to the YAML layer and define a datetime data type down there. That would work. But TAP is the wrong layer for this.) > If RFC3339 is forward compatible with ISO8601 then I'm happy. > We can start simple and upgrade to ISO8601 if RFC3339 proves > too restrictive. I am not certain of this, but my understanding is that RFC 3339 datetimes are always valid ISO 8601 datetimes also; that RFC 3339 is a profile of ISO 8601. Certainly there’s nothing you can express in RFC 3339 format that you can’t also express in ISO 8601 format. > 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. RFC 3339 is explicitly about instant-in-time information, so no, it does not allow shorthands like that. Is there a use case in TAP for saying “this happened on day so-and-so” or “it happened at time so-and-so”, but omitting the time or date (respectively), rather than just providing a full datetime in all cases? Or even say “it happened in 2007” with no further qualification? (Remember, the app’s date format should be up to the app; I’m asking purely about metainformation in the TAP. Some apps will quite obviously need this for their data, but that’s a different kettle of fish.) > > 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". Ah. But you don’t answer the question whether there’s need for cases like that in the metainformation. (Again, not in the app data; it’s clear that there will *sometimes* be a need for that there.) Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
