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

DATETIME September 2011

Subject:

specification review

From:

Syd Bauman <[log in to unmask]>

Reply-To:

[log in to unmask]

Date:

Fri, 2 Sep 2011 12:11:48 -0400

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (100 lines)

My apologies for having been away so long, and for not having kept up
with the conversation. I have a vague recollection, though, that
someone posted a request for comments by today. So I'm going to go
through the specification and post comments today, even though I don't
have time to read the conversations I've missed. So please forgive me
if I head down paths already tread thoroughly.


002
---
The rules need to be clearer about zone offsets. Not clear to me what
"Either format may be used" means. My suggestion would be to stick to
ISO 8601 extended, and *not* to permit the basic format. (Extended
has a colon iff minutes are present, basic does not.) (And note that
"Z" is not an alternate format: ISO 8601:2004 does not permit
"+00:00" or "-00:00" AFAIK.)

So I'd end the rules at the semicolon, and add a note:

    ISO 8601 extended format time zone designation consists of either
    a "Z" to indicate UTC, or a "+" (ahead of UTC) or "-" (behind
    UTC) followed by a 2-digit hour, followed optionally by a colon
    and the 2-digit minutes.

004
---
Insert "endpoint" between "Either" and "may be".

101
---
* The word being defined is capitalized in all cases except
  "uncertain". 

* Is the explanation of the assumed model needed? Why not just "the
  source for a particular date is dubious."?

102
---
* It would be useful, IMHO, to add examples to #3 and #4 in the list
  in the Syntax/rules column.

* Why not unspecified month with known year and day? (Actually
  happens to us occasionally in a diary -- fictional example: it says
  "6th", so we know the day is 06; it says "Sarah told me ...", and
  we know Sarah was only visiting in 1732; but the month is
  unspecified, and while we may be able to figure it out someday ...)

103
---
* The short explanatory blurbs after some of the examples in
  "Examples" column are quite useful; I think all of the examples
  should have one.

* It is probably worth repeating in the "Syntax/rules" column that an
  interval is represented by two "dates" separated by a solidus (aka
  forward slash).

104
---
I am very glad to see that expressions of years with > 4 digits
is unambiguously indicated with a preceding 'y'. I presume, though,
that you cannot be convinced to completely remove this syntax from
the specification (else it would have already been removed given the
strong arguments for doing so previously put forth).

Can I at least convince you to move it to level 2? Remember that if
you want this to get any traction at all, people have to write
software to at least validate expressions, if not process them. Every
syntax you add makes it harder to write that software. So
introduction of a syntax is a cost/benefit analysis. In this case,
the cost is not particularly high, but the benefit is infinitesimally
small.

So let's at least move the trouble of writing code that will
basically never get used to those doing a lot of work already,
anyway.

105
---
The subsection "Sorting Seasons" is not about sorting seasons, but
rather is about sorting LOC extended dates altogether. I think the
subsection here should just talk about seasons, and refer the reader
to an entire section elsewhere on ordering in general:

  For ordering purposes, seasons may be sorted with Spring < Summer <
  Autumn < Winter. However, the relationship between a season and a
  date is not determined by this specification. Thus "2011-21" should
  sort before "2011-23", but applications may choose to sort "2011-21"
  and "2011-10" either way, or consider them incomparable. For a
  complete discussion of the order relationship among LOC date and
  time representations, see XXXX.

That section on order relations may be thorny, though.

But if the current wording is kept, there is an extraneous space
between "thus the value '" and "2000', for purposes".


Will try to take a look at level 2 and the BNF after lunch.

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