LISTSERV mailing list manager LISTSERV 16.0

Help for DATETIME Archives


DATETIME Archives

DATETIME Archives


DATETIME@C4VLPLISTSERV01.LOC.GOV


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Monospaced Font

LISTSERV Archives

LISTSERV Archives

DATETIME Home

DATETIME Home

DATETIME  February 2013

DATETIME February 2013

Subject:

Re: Precision better than one second

From:

Saašha Metsärantala <[log in to unmask]>

Reply-To:

Discussion of the Developing Date/Time Standards <[log in to unmask]>

Date:

Sat, 16 Feb 2013 17:07:48 +0100

Content-Type:

TEXT/PLAIN

Parts/Attachments:

Parts/Attachments

TEXT/PLAIN (72 lines)

Hello!

> 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:

2013-02-16T02:03.01

In EDTF, this 2013-02-16T02:03.01 ISO_8601 data could be rounded as

2013-02-16T02:03:01

(where one hundredth of a minute is rounded to one second) or truncated as

2013-02-16T02:03:00

or approximated to

2013-02-16T02:03:01.67

or approximated to

2013-02-16T02:03:01.66666666666666666666666666666667

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
described at
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
from ISO_8601.

Regards!

SaaĊĦha,

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

August 2019
February 2019
December 2018
November 2018
October 2018
January 2018
August 2017
July 2017
June 2017
April 2017
March 2017
February 2017
August 2016
July 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
December 2014
November 2014
March 2014
September 2013
May 2013
February 2013
October 2012
September 2012
August 2012
May 2012
March 2012
December 2011
November 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
February 2010
January 2010
December 2009
November 2009

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager