> I think the balance is strongly in favor of adding fractional seconds
I agree, but we need a more accurate description of how we want this
feature to be implemented. Please read below!
> it's easy for a programmer to handle the 8601 syntax.
To avoid possible misunderstandings, could we clarify WHICH of the several
ISO_8601 syntaxes we wish to use for this feature? I suggested the syntax
for fractional seconds used by xsd:dateTime and wonder whether someone
would prefer any other among ISO_8601's several syntaxes for this feature.
> > If two EDTF applications process the same ISO 8601 data, and one
> > truncates while the other rounds, they will potentially produce
> > different results.
> Good point.
The problem is indeed more complicated than that, because ISO_8601 also
allows fractional minutes and fractional hours. I consider that we should
specify HOW incoming ISO_8601 fractional hours and ISO_8601 fractional
minutes should be handled (or clarify in the EDTF specification that this
question is implementation dependent). Let's consider incoming ISO_8601
data such as:
In EDTF, this 2013-02-16T02:03.01 ISO_8601 data could be rounded as
(where one hundredth of a minute is rounded to one second) or truncated as
or approximated to
or approximated to
etc. I would tentatively suggest that, when serialized to EDTF, ISO_8601
fractional hours and ISO_8601 fractional minutes should be rounded in the
spirit of the round-Ties-To-Even algorithm (sometimes called half to even
rounding) with nine decimal digits after the dot. The reasons for choosing
nine decimal digits is that:
- Operative systems seldom use fractions of nanoseconds
- A nine digit decimal integer can be losslessly stored as a 32-bits signed integer
The reasons for choosing round-Ties-To-Even is that IEEE_754 available at
http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=4610935 suggests at
the bottom of page 16 that
> The default rounding-direction [...] should be roundTiesToEven
(which is defined in the middle of the same page) and I consider that this
would probably be a good choice for conversions from ISO_8601 fractional
hours and ISO_8601 fractional minutes to EDTF. What do you think?
The next question is whether the number of decimal digits after the dot in
EDTF-born data should be potentially illimited as it is in xsd:dateTime
http://www.w3.org/TR/xmlschema11-2/#con-dateTime-day or whether it should
be limited to the same (or another) number of digits as EDTF converted