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  January 2011

DATETIME January 2011

Subject:

Re: comments on draft EDTF spec of 5 Nov 2011

From:

Ray Denenberg <[log in to unmask]>

Reply-To:

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

Date:

Tue, 11 Jan 2011 17:16:34 -0500

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (82 lines)

 From: C. M. Sperberg-McQueen
 Sent: Tuesday, January 11, 2011 1:14 PM

Addressing remaining issues (not covered in other threads)

> 3 What problem is being solved here? What are the requirements?
>
> The goals and requirements of the work are not clear (to this reader,
> at least) from the document. The section 'Background' begins with the
> promising statement
>
> No standard date/time format meets the needs of XML metadata
> schemas.
>
> But the document does not seem to provide any list of what its authors
> believe the needs of XML metadata schemas are, or why no existing
> standard date/time format meets them.

While I have for the past couple months worked to maintain the spec page,
the other pages, background, requirements, etc., have suffered from lack of
attention. My fault, and I will turn my back attention to them soon.

My colleague Rebecca Guenther has been working closely (though relatively
silently) with me on this and I have asked her to address issues of use
cases, requirements, etc, so look for a message from her in a day or so.



> 4 Why a single datatype?
>
> Is it a requirement that all of these formats be defined as lexical
> forms for a single datatype?

No, it is not a requirement, it is a design strategy. It is open for
discussion.

 
> Is an interval really the same as a duration the same as a date the
> same as a time the same as a date-time pair?

No. The spec defines a syntax for an interval, and a different syntax for
duration, and syntaxes for time and date-time pairs. I'm sure I'm
misunderstanding your question so please elaborate.



> 6 What operations are expected?
>
> When sorting by values of this type, how should questionable,
> approximate, and uncertain dates be handled? How does a time like
> 22:00:22 compare to a date like 2011W02?

I would think it reasonable to declare these out-of-scope for the spec and
the responsibility of the application that defines or uses the data.

> 7 The year zero
>
> Entry 110 reads in part
>
> BC has no year zero, In the BC system the year before year 1 is 1
> BC. Thus '-0999' means "1000 BC".

No longer. BC and AD are no longer discussed in the spec so this is no
longer an issue.

 
> And ISO 8601 sets a heroic example of allowing a multiplicity of forms
> while ensuring that any form conforming to the spec is unambiguous. It
> looks at first glance as if allowing hyphen to separate the start and
> end points of a range or interval (as shown in 317 and 319) is safe,
> because the hyphen (or double hyphen, in 319) is followed by four
> digits, not two or three. If you have done the work necessary to
> guarantee that you are preserving 8601's lack of ambiguity, it might
> be worth saying so in the prose; if you haven't done the work, it
> would be useful to do it.
>

We're currrently re-examining whether we need to keep the compact form in
the spec, so I will defer this exercise until we resolve this.

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