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

DATETIME April 2011

Subject:

Re: Some comments about the BNF

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, 20 Apr 2011 14:09:37 -0400

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (192 lines)

 From: Saašha Metsärantala
> [1] The BNF accepts a date equal to "00", which according to our
> specification refers to the first century. The BNF also accepts a date
> equal to "-00" which semantics are not clarified in our specification.
> I wonder whether the date "-00" refers to the century before "00" or if
> "-00" should be considered non-sensical. 

Just as "00" means "00xx" where xx is any two digit number,
"-00" would mean -"00xx" where xx is any two digit number. 

So "00" would be 0000, 0001, 0002, ..., 0099
and "-00" is 0000, -0001, -0002, ..., -0099

If you want to call the first of these the "first century" and the second the "century before" feel free, but the spec is careful not to define the concept of century, and note that these two periods overlap (they both include 0000), all the more evidence of the futility of defining "century".




I would appreciate a
> clarification in our specification. Furthermore, the BNF accepts "-
> 0000"
> as a year. Considering both "-00" and "-0000" as non-sensical, I would
> suggest the following modifications in the BNF

I would prefer not to make the rather extensive changes that you have suggested  to avoid negative zero.  I'd prefer to just say that there is no disinction between negative and positive zero, they are both zero.


 
> [2] The BNF accepts dates such as 2011-02-29. Does anyone else would
> prefer to reformulate the BNF to avoid such non-sensical "dates"?

I believe it would be a futile exercise to try to validate a leap year. While we may be able to safely assert that 2011 is (was) not a leap year and thus 2011-02-29 is not a valid date, and we're fairly confident that 2013-02-29 won't be, can you say with complete confidence that, say 2213-02-29 won't be a leap day? Or for that matter that 2212-02-29 will? Who knows, in a hundred years leap day may be in November, so there could be a 2111-11-31. 


 
> [3] The zoneOffset accepts "+14:30" but refuses both "-00:30" and
> "+00:00". I would suggest a reformulation of the lexical space in the
> BNF (slightly stricter than the W3C XML Schema 1.1, but keeping the
> same value space than the W3C XML Schema 1.1 - compare 4. in the e-mail
> I sent to the list on April, 6th).
> 
> > zoneOffset = "Z" | (+|-) zoneOffsetHour ":" minute
> zoneOffset = "Z" | (+|-) ( zoneOffsetHour ":" minute | "14:00" | "00:"
> oneThru59 ) | "+00:00"
> 
> > zoneOffsetHour = oneThru14
> zoneOffsetHour = oneThru13
> 
> oneThru13 = oneThru12 | "13"
> 
> oneThru59 = oneThru31 | "32" (* etc. *) | "59"

Ok, I've made changes functionally equivalent to these suggestions.


> [4] I do not find anything about fractions of seconds in our
> specification. Maybe it should be added there. Otherwise, fractions of
> seconds could be removed from the BNF.

I've removed fraction of second from the BNF.  


> 
> [5] According to the W3C XML Schema 1.1, let us skip leap seconds (and
> leap minutes):
> 
> > minute = zeroThru60
> minute = zeroThru59
> 
> > second =  zeroThru60
> second =  zeroThru59
> 
> zeroThru59 = "00" | oneThru59

Ok.


> 
> [6] A short simplification:
> 
> > inclusiveListElement ("," inclusiveListElement)* "," later
> (inclusiveListElement ",")+ later

I completely rewrote the list part last week.


I will get to the rest of your comments as soon as I can.

Thanks.

--Ray




> Now, I will try to clarify what I described about lists in the e-mail I
> sent on April, 1st.
> 
> [7] The BNF #316 for a choice list does not accept [1970..1973] and
> requires a reformulation like [1970, 1971..1973]. If I misinterpret our
> specification, a clarification may be needed. As I interpret our
> specification, choice lists like [1970..1973] should also validate.
> Therefore, I would suggest the following modifications:
> 
> > choiceListContent = choiceListElement (“,” choiceListElement)+
> choiceListContent = choiceListElement (“,” choiceListElement)* (* with
> an asterisk instead of a plus sign *)
> 
> > choiceListElement = date | date “..” date | earlier | later
> choiceListElement = date "," date | date “..” date | earlier | later |
> date "," choiceListElement | choiceListElement "," date
> 
> Furthermore, the numbering #317, #3171 and #316 in our specification is
> in a non-intuitive order.
> 
> [8] Likewise, the BNF for inclusiveList accepts {1970, 1971..1973} but
> not {1970..1973}. As I interpret #317 in our specification, {1970..1973}
> should validate.
> 
> [9] interval:
> 
> > yearDuration
> yearsDuration
> 
> > yearMonth "/P" monthsDuration
> yearMonth "/P" ( yearsDuration )? monthsDuration (* read below *)
> 
> > yearMonthDay "/P" daysDuration
> yearMonthDay "/P" ( ( yearsDuration ( monthsDuration | "0M" )) |
> monthsDuration )? daysDuration (* maybe *)
> 
> [10] duration:
> 
> The BNF does not mention times (hours, etc.) for duration, whereas both
> our specification and the W3C XML Schema 1.1 do. Furthermore, the
> following expression
> 
> > (yearsDuration ((monthsDuration | "0")(daysDuration | "0")?)?)
> probably may need to be reformulated to maybe:
> 
> ( yearsDuration ( monthsDuration | ( ( monthsDuration | "0M")
> daysDuration
> ) )? )
> 
> and
> 
> > monthsDuration = positiveInteger "M"
> monthsDuration = oneThru11 "M"
> 
> oneThru11 = "01" (* etc. *) | "11"
> 
> oneThru12 = oneThru11 | "12"
> 
> [11] longYear
> 
> The uppercase "Y" may need to be changed to lowercase "y". Furthermore,
> the dot (period) before the "e" does not match our specification. The
> BNF does not either accepts "1.7e8" as described in our specification.
> I would suggest to avoid decimal dots because, it makes it easier to
> write a BNF that do not allow non-integer years, such as 1.2345e3 and
> it solves the problem with different decimal separators in different
> countries (often dots or commas).
> 
> Thus, I would suggest "17e7" instead of "1.7e8", etc. in our
> specification and one suggestion to modify the BNF could be the
> following:
> 
> > longYear = "y" "-"? positiveDigit ".e" yearExponent | "Y" "-"?
> > positiveDigit digit digit digit digit+
> longYear = "y" "-"? positiveDigit ( digit )* ( "e" yearExponent | digit
> digit digit digit)
> 
> [12] season
> 
> What about choosing the caret character (^) before the qualifier, in
> analogy with the calendar?
> 
> [13] A few words about a small typo in the proposal for internal
> uncertain/approximate
> 
> > monthDay = baseMonthDay | "("baseDayMonth")" ("?" | "~")
> monthDay = baseMonthDay | "("baseMonthDay")" ("?" | "~")
> 
> and according to #301 and #306 in our specification
> 
> > year = baseYear | "("baseYear")" ("?" | "~")
> year = baseYear ("?" | "~") (* without parenteses around the year *)
> 
> 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