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:

Proportional Font

LISTSERV Archives

LISTSERV Archives

DATETIME Home

DATETIME Home

DATETIME  January 2011

DATETIME January 2011

Subject:

Re: Comments on draft edtf specification

From:

"Ray Denenberg, Library of Congress" <[log in to unmask]>

Reply-To:

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

Date:

Wed, 5 Jan 2011 18:08:29 -0500

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (95 lines)

Hi Betsy, thanks for your comments and welcome to our forum. 

> 1.) Im not clear about item #2 under Standard Features. The label
> says Date/time - without hyphen/colon. However, the example uses
> hyphens:
> 2001-02-03T093001

That was an error, thanks for catching it, I've removed the hyphens.

> 2.) Hyphens: The option express to a date without a hyphen is
> appealing. Without the hyphen, the date looks elegantly
> simple. However, this option creates too much complexity. Systems
> will possibly have an extra format to parse. It also leads to possible
> data errors. How to remember it is okay to use 19990415 to represent
> year, month, and day, but not okay to use
> 199904 to represent a year and month?

I don't think there is any way around this problem though I would welcome
further discussion.  I do not think we could get agreement to profile out
the separated forms (hyphens in dates and colons in times) because that's
the form that W3CDTF uses and I don't think this spec is going to go
anywhere if it does not accommodate W3CDTF.  And on the other hand, part of
the motivation for beginning the work on this spec was to add the
non-separated forms. I think we're stuck with this complexity.


> 3.) Further complicating the hyphen issue, it looks like section 3 only
> permits questionable dates to be represented without the hyphen:
> 20040611? Is 2004-06-11? permissible? Im not seeing an example
> formatted that way.

Yes, there's no intention to restrict "questionable" (etc.) to unseparated
values.  The description of the '?' etc. characters' syntax is that "they
apply either to the entire portion of the string to their left, unless
immediately preceded by parenthesis, in which case they apply to the portion
of the string delimited by parentheses."  The key being "the string"
whatever that string may be.  The examples are not intended to be
comprehensive. The spec at this point is a tool to achieve a stable
consensus on the proposed standard, and then a more formal spec perhaps
including a BNF definition will need to be written. 


> 4.) Unspecified years, days, and months can be represented with the
> letter u. From the examples: 199u, 1999-uu, 199901uu. However, when
> only the century is known, the letter u is not used to fill in the
> missing digits: 19 is used for sometime in the 20th century. It seems
> like if were going down the path of using the letter u, we might as
> well use it in the century coding (19uu) as well in order to be
> consistent. 

Actually, no, '19' would not mean "SOMETIME in the 20th century" it would
mean "THE 20th century".

There has been a great deal of discussion of this and surrounding issues but
let me start out by saying that the only reason why in our spec '19'
means"the 20th century" is that that's what it means in ISO 8601, and one of
the principles of this work is that whatever we want to express, if it is
expressible in ISO 8601 then this spec should at least specify that syntax
even if it perhaps specifies alternative syntaxes not specified in ISO 8601.


The case of century is particularly troubling because we cannot even agree
what it means. Some of us believe that the 20th century began in 1901 and
others believe it began in 1900. ISO 8601 doesn't help resolve this because,
even though it tells you how to represent a century, it doesn't tell you
what a century is.  And it is fairly clear to me that we are not going to
agree to a definition and are going to have to leave it undefined. 

But there is a way to represent the interval consisting either of the years
(1) 1900 through 1999, or (2) 1901 through 2000:

(1) 1900/1999  or 1900--1999
(2) 1901/2000 or  1901--2000

So I think we should keep '19' in the spec to mean "19th century"
(undefined) for reasons I stated above, with the general guidance that if
you have a specific interval you want to represent you'd be better off using
one of these two forms.  If on the other hand you want to designate during
what century World War II occurred, '19' is probably good enough. 

But I digress from the point you raised. The spec would indeed support
'19uu' to mean "some unspecified year between 1900 and 1999".   If what you
want to say is the event occurred "sometime during the period between 1900
and 1999" -- it is a matter somewhat outside the scope of the spec to say
whether 1900/1999 means
(1) an instant in time during that period, or 
(2) the entire interval

That would be a semantic matter for the applcation which references the spec
to specify.

I hope this helps. Thanks again. 

--Ray

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