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

DATETIME May 2015

Subject:

Re: Long Years vs. Expanded Representations; forms with century vs. year precision

From:

"Byrd, Donald A." <[log in to unmask]>

Reply-To:

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

Date:

Fri, 15 May 2015 00:48:04 +0000

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (162 lines)

Since Edward Zimmerman hasn't spoken up, I'll jump in and say I also feel strongly that the semantics of  "(NN+1) century" and "NNxx", where the N's are digits, are not identical. The former has a precision of a century, the latter a precision of a year. For example, the American Revolution occurred in the 18th century; since it lasted much longer than a year,  saying it occurred in 17xx is simply wrong. On the other hand, for when the composer Perotin was born, you could equally well say either 11xx or the 12th century.

--DAB


On May 11, 2015, at 4:58 PM, "Denenberg, Ray" <[log in to unmask]> wrote:

> Yes, makes complete sense now, and thanks.
>  
> The possibility of using masked precision in the manner you suggest was not discussed (as I recall), but there is a reason why it would most likely have been rejected.  Basically, the semantics of ‘19xx’ would not quite be the same as the semantics of “20th century”. The reason has to do with the concept of “precision”. 
>  
> We do have a resident expert on “precision” on this listserv, Edward Zimmerman, I hope he’s listening and if so, certainly he will elaborate. 
>  
> Ed was(is)  quite passionate about the concept of precision, and while not all of us shared his passion, he was a significant contributor to the spec and we deferred to his expertise in this matter.
>  
> The argument would go  something like this.   ‘19xx’ represents a year: an unspecified year within the 20th century.  The semantics of “20th century” are not quite so specific.
>  
> Hope that helps, and hopefully Ed will weigh in.
>  
> Ray
>  
> From: Discussion of the Developing Date/Time Standards [mailto:[log in to unmask]] On Behalf Of Nathan Harrenstein
> Sent: Saturday, May 09, 2015 12:15 AM
> To: [log in to unmask]
> Subject: Re: [DATETIME] Long Years vs. Expanded Representations
>  
> In ISO 8601:2004(E), dates can be expressed in either "complete representations" or "representations with reduced accuracy". Dates of the form "±YYYYY-MM-DD" or "±YYYYYMMDD" are called complete representations. The day, the month, or the latter half of the year may be omitted from a complete representation, in which case the date is referred to as a representation with reduced accuracy. This includes a specific month "±YYYYY-MM", a specific year "±YYYYY" or a specific century "±YYY".
> 
> This feature requires the agreement on the number of added digits between interchange parties because otherwise it would not be clear if a date such as "+00019" referred to the 20th century or the year 19. If it was known that the time element was expanded by three digits, then "+00019" would mean the 20th century because adding three digits to five means that there must have been two digits to begin with, and a year must have at least four digits. However, if the time element is known to have been expanded by one digit, then "+00019" would mean the year 19 because there must have been four digits to begin with. Without knowing how many digits were added, the expression "+00019" is ambiguous and could represent either the 20th century or the year 19.
> 
> The EDTF "long year" feature with the "y" prefix does not support representations with reduced accuracy insomuch as months, days, and centuries are unsupported (e.g. y00019 would never mean the 20th century). Because long years do not support these forms of reduced accuracy, there is no ambiguity and therefore no need for prior agreement on the number of digits between interchange parties.
> 
> Does this accurately summarize the rationale for adding the long year feature? Would it not be simpler to alter expanded representations such that the centuries are notated using masked precision and only the extended format of expanded representations are supported (i.e. ±YYYYY-MM-DD is supported but not ±YYYYYMMDD)? For example, "+019xx" would refer to the 20th century, "+00019" would refer to the year 19, and a full date would be written "+00019-12-25". Then the feature that already exists is improved instead of working in another similar feature.
>  
> Hopefully some of this makes sense,
> Nathan
>  
> On Fri, May 8, 2015 at 12:19 PM, Denenberg, Ray <[log in to unmask]> wrote:
> I’m sorry but I don’t understand the first question.
>  
> On the second, the need for prior agreement certainly makes a spec less interoperable (if not nonstandard) which is one reason we came up with an alternative approach.
>  
> Ray
>  
> From: Discussion of the Developing Date/Time Standards [mailto:[log in to unmask]] On Behalf Of Nathan Harrenstein
> Sent: Thursday, May 07, 2015 2:49 PM
> 
> To: [log in to unmask]
> Subject: Re: [DATETIME] Long Years vs. Expanded Representations
>  
> So if I understand correctly, long years do not support any form of reduced accuracy to avert any ambiguities between centuries and years that would necessitate an agreement on the number of digits between parties?
>  
> Wouldn't the need for prior agreement between parties make expanded representations, in a sense, nonstandard?
>  
> Nathan
>  
> On Thu, May 7, 2015 at 7:15 AM, Denenberg, Ray <[log in to unmask]> wrote:
> 'otherwise a string like "+1919" might mean the year 1919 or the century beginning in 191901. I think.'
> 
>  
> 
> Small point, but I would say " a string like 191901 might mean the year 191901 or it might mean January, 1919".   
> 
> 
> Ray
> 
>  
>  
> 
> > -----Original Message-----
> 
> > From: Discussion of the Developing Date/Time Standards
> 
> > [mailto:[log in to unmask]] On Behalf Of Byrd, Donald A.
> 
> > Sent: Thursday, May 07, 2015 9:38 AM
> 
> > To: [log in to unmask]
> 
> > Subject: Re: [DATETIME] Long Years vs. Expanded Representations
> 
> >
> 
> > I Even aside from the "exponential" notation, these features aren't the same.
> 
> > ISO 8601 says years with more than four digits must be agreed on by the
> 
> > parties, and it strongly implies that an exact _number_ of additional digits
> 
> > must be agreed on. (Which makes sense in that otherwise a string like
> 
> > "+1919" might mean the year 1919 or the century beginning in 191901. I think.)
> 
> > In EDTF, years with more than four digits can always be used, and there's no
> 
> > need for (or point to!) agreement between the parties. So EDTF's
> 
> > representation is more standardized and well-defined -- and much better,
> 
> > IMO.
> 
> >
> 
> > --Don
> 
> >
> 
> >
> 
> > On May 7, 2015, at 1:14 AM, Nathan Harrenstein
> 
> > <[log in to unmask]> wrote:
> 
> >
> 
> > > I was reading the ISO 8601:2004(E) standard and noticed that there is
> 
> > already a feature for representing long years, called "expanded
> 
> > representations" (§4.1.2.4). Reading through the EDTF listserv archives, I got
> 
> > the impression that this feature was not known at the time long years were
> 
> > ideated.
> 
> > >
> 
> > > "By mutual agreement of the partners in information interchange, it is
> 
> > > permitted to expand the component identifying the calendar year, which is
> 
> > otherwise limited to four digits. This enables reference to dates and times in
> 
> > calendar years outside the range supported by complete representations, i.e.
> 
> > before the start of the year [0000] or after the end of the year [9999]" (§3.5).
> 
> > >
> 
> > > To specify an "expanded representation", the year is prefixed by a "+" or "-
> 
> > ". It doesn't cover the scientific notation features, however.
> 
> > >
> 
> > > Am I missing something or are these features the same?
> 
> > >
> 
> > > Nathan
> 
> >
> 
>  

---
Donald Byrd
Woodrow Wilson Indiana Teaching Fellow
Adjunct Associate Professor of Informatics
Visiting Scientist, Research Technologies
Indiana University Bloomington

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