With regard to precision better than one second, I'm not arguing against it, it's my job to keep complexity down to the necessary minimum, and as such I have to play devil's advocate.

 

From: Byrd, Donald A.

> And second, I have the impression that EDTF Level 0 can express virtually

> everything 8601 can express _except_ fractional seconds  

 

Well, no, there are a number of features not included:

 

Duration

ordinal date

week date

calendar week number

recurring time interval

century

time interval using duration

 

(to name a few)

 

  I hesitate to mention these because I really would not want to see these issues re-opened, without good cause.  "Good cause" would be someone new joining this forum who intends to implement or use this specification and has a concrete use case. (Or someone old, with a new use case.)  This would apply not only to the above list but as well to decimal seconds - there may be arguments why we should include it, but I'm not sure we have a concrete use case.  I'm not sure we don't, but to say "we need timestamps with precision better than 'second' " may be an argument in favor, but it is not a use case. (Ed has provided a wealth of valuable and interesting knowledge to the process, but his use cases - e.g. Babylonian Barleycorn - are -- how do I put this? --  sometimes difficult to take seriously.)

 

With regard to fraction of  a second, 8601 allows expression of fraction of an hour and fraction of a minute.  I presume that those who want the fraction feature would limit it to fraction of a minute.  

 

8601 also says that interchange parties should prescribe the number of decimal digits. Also, period or comma may be used.  "Interchange parties" in this context would mean the EDTF spec, so the spec would have to indicate a number of digits, and whether period or comma is to be used (and I certainly hope it would be period).

 

From: Gerard Ashton

> Following up on Donald Byrd's argument, it's possible code reuse and data

> reuse may both occur with applications that use the full ISO 8601 standard.

> In this situation, it would be necessary to modify code that might

> otherwise be reused to make sure that any data coming into an EDTF

> application does not contain fractional seconds,

 

EDTF supports intervals, but only in the form of start/end. So if an interval comes in in the form of start/duration you have a similar problem, don't you?    

 

I understand the argument about reuse of code, in this case a "full implementation" of 8601.  But that's what got us into this process to begin with - too many ways to do too many things in 8601, which is the reason for a profile. So there is a tradeoff: the down side - some lack of flexibility to reuse existing software; the upside, significant simplification and increased interoperability.

 

> If two EDTF applications process the same ISO 8601 data, and one truncates

> while the other rounds, they will potentially produce different results.

 

Again, not necessarily arguing one way or the other, this seems solvable by including guidance within the spec, saying in effect, that an EDTF application receiving data with a fractional seconds, if it chooses to accept that data, should truncate.

 

Ray