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 2016

DATETIME February 2016

Subject:

Re: Accuracy vs. Precision

From:

"Edward C. Zimmermann" <[log in to unmask]>

Reply-To:

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

Date:

Tue, 9 Feb 2016 20:08:54 +0100

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (90 lines)

We can, I think, argue that their semantics for accuracy assumed zero bias and
subsummed BOTH precision (readability) and accuracy.
ISO 5725 defines accuracy to mean the closenest to the true value and
precision as the closeness of agreement among a set of results. Should one
take every expression of date as known and true they, of course, align.
We have now, however, extended things in EDTF to contain concepts such as
uncertainty, belief, information, knowledge etc. and thus must explicitly
seperate the two concepts. As I suggested I'm, in fact, not sure if we should
even continue to speak of "accuracy" in the context of ISO 8601 as we have no
ground truth, no universal consensus of what a true value can be. What remains
is our concept of precision (readability) and our belief. I understand that
following that path might be "too philosophical" for some...
But.. I think wecan also argue that we need to pull accuracy and precision
apart alone due to our use of unknowns which were not art of 8601.
Look at date expressions like 196u-12-12. To speak of that date as accurate to
day is completely foolish. We don't even know the year. It's accuracy is
within a decade. The "true" date might end up being 1962-12-12 but it could
also end up as 1969-12-12. We know it was 12 Dec. We know that it was in the
1960s. While an expression such as 1969-12-12 could be in this light
considered as both precise to date and accurate to date all those other
expressions where we have unknowns or express uncertainty etc. don't and can't
show this kind of conceptual aligment...


 


On Mon, 8 Feb 2016 10:57:09 -0500, Denenberg, Ray wrote
> [UTF-8?]“I find it troubling that an ISO committee is confusing terms
taught in primary school [UTF-8?]science.”
>
> Just to be clear, it [UTF-8?]isn’t the ISO committee [UTF-8?]that’s
confusing these concepts [UTF-8?]– [UTF-8?]it’s ISO in general. The
committee draft has been reviewed by ISO editors (outside the committee) who
have suggested that we change terminology (in the new material) to conform to
existing ISO terminology, which uses [UTF-8?]“accuracy” rather than [UTF-
8?]“precision”. For example, see the excerpt below from ISO 8601-2004
[UTF-8?]“Complete [UTF-8?]Representation” vs. [UTF-8?]“Representation
with reduced [UTF-8?]accuracy”. [UTF-8?]“Accuracy” here should instead
be [UTF-8?]“precision”, but it has been [UTF-8?]“accuracy” since the
first version of 8601 (many years ago) and nobody has noticed (or perhaps
nobody cared enough, since the misuse of the terminology really has no effect
on interoperability). Our committee is not tasked with nor does it have the
authority to fix this sort of thing, however, we are arguing that that does
not mean we have to carry this mistake over to new material.
>
> I just wanted to make it clear that the members of the current committee do
understand the difference between these concepts.
>
> Ray
>
>
______________________________________________________________________________
___________
> 4.1.2.2 Complete representations
> When the application identifies the need for a complete representation of a
calendar date, it shall be one of
> the numeric expressions as follows, where [YYYY] represents a calendar year,
[MM] the ordinal number of a
> calendar month within the calendar year, and [DD] the ordinal number of a
calendar day within the calendar
> month.
> Basic format: YYYYMMDD Example: 19850412
> Extended format: YYYY-MM-DD Example: 1985-04-12
> 4.1.2.3 Representations with reduced accuracy
> If in a given application it is sufficient to express a calendar date with
less accuracy than a complete
> representation as specified in 4.1.2.2, either two, four or six digits may
be omitted, the omission starting from
> the extreme right-hand side. The resulting representation will then indicate
a month, a year or a century, as
> set out below. When only [DD] is omitted, a separator shall be inserted
between [YYYY] and [MM], but
> separators shall not be used in the other representations with reduced
accuracy.
> a) A specific month
> Basic format: YYYY-MM Example: 1985-04
> Extended format: not applicable
> b) A specific year
> Basic format: YYYY Example: 1985
> Extended format: not applicable
> c) A specific century
> Basic format: YY Example: 19
> Extended format: not applicable


--

Edward C. Zimmermann, NONMONOTONIC LAB

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