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

DATETIME February 2017

Subject:

Re: Long Years in EDTF

From:

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

Reply-To:

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

Date:

Mon, 27 Feb 2017 17:05:57 -0500

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (1 lines)

Yes I was speaking only of into the future, not the past.  I do not make a case for representing arbitrarily distant years into the past because we know (or assume) the universe only goes back so far.  We don't know how long the universe will exist (despite predictions) and so I think there is a valid case for representing arbitrarily distant years into the future.

Ray

> -----Original Message-----
> From: Discussion of the Developing Date/Time Standards
> [mailto:[log in to unmask]] On Behalf Of GERRY ASHTON
> Sent: Monday, February 27, 2017 4:09 PM
> To: [log in to unmask]
> Subject: Re: [DATETIME] Long Years in EDTF
> 
> Regarding years in the distant past or future, it is crucial to recall that the only
> allowable calendar for ISO 8601 is the (possibly proleptic) Gregorian calendar,
> and throughout the history of that calendar, it has observed solar days, not
> days of uniform duration such as International Atomic Time, Terrestrial Time,
> Ephemeris Time, etc. Thus, it is invalid to represent a date in ISO 8601 when
> what is really known is the date in a uniform time scale, and the date
> measured in observed solar days does not fall within the uncertainty implied
> by the expressed date. For example, if an event is known to have occurred in
> the middle of -3000 Terrestrial Time, the ISO 8601 expression "-3000" is valid
> because TT differs from UT by less than a day at that time. But the ISO
> expression "-8000000000" is invalid since the Earth did not exist and therefor
> days did not exist.
> 
> > On February 27, 2017 at 8:39 PM "Denenberg, Ray" <[log in to unmask]>
> wrote:
> >
> >
> >
> > Christoph Päper  has suggested changes to the “Year exceeding four digits”
> provision of DIS 8601-2, which currently reads:
> >
> > 4.5 Year exceeding four digits
> > Part 1 of this standard allows a year to exceed four digits (a year after 9999
> or before -9999) however it requires mutual agreement of the partners in
> the information exchange.
> >
> > Presented here is an alternative method, which does not require mutual
> consent. It may be used only for dates where only the year is significant, not
> the month or day.
> >
> > 4.5.1 Level 1
> > 'Y’ may be used at the beginning of the date string to signify that the date is
> a year, when (and only when) the year exceeds four digits, i.e. for years later
> than 9999 or earlier than -9999.
> >
> > Format:
> >
> >
> >  *   “Y”YYYYY…..
> >  *   “Y-”YYYYY…..
> >
> > Examples:
> >
> >
> >  *   Y170000002
> > (the year 170000002)
> >  *   Y-170000002
> > (the year  -170000002)
> >
> > 4.5.2 Level 2
> > Level 2 presents an alternative, exponential form.  'E' is used to mean
> "times 10 to the power of" thus 17E8 means "17 times (10 to the eighth
> power)", or 170000000000. (And as in level 1.'Y' at the beginning of the string
> indicates "year”.)
> >
> > Examples:
> >
> >
> > ·         Y17E7
> > the year 170000000
> >
> > ·         Y-17E7
> > the year -170000000
> >
> >
> >
> >
> >
> > The suggestion is to use SI prefixes rather than exponential form.  See for
> example http://members.optus.net/alexey/prefSI.xhtml . So ‘Y17E7’, would
> become ‘Y170M’, etc.
> >
> > I do not think this approach would be practical for a number of reasons.
> First, It would introduce several new characters into the standard, all of
> which would have to be listed if they are to be part of the 8601 syntax.  Some
> of these characters are used for other purposes – P, T, and Y for example,
> and while the use of such characters can be disambiguated by context, the
> ISO group still most likely would not allow this sort of dual use. Furthermore,
> some of these characters are lower case, and lower case characters cannot
> be introduced into the syntax (by convention). Finally, it is suggested that
> representation of years greater than 14 billion is not necessary (the
> suggested estimate of the  remaining lifespan of the universe) and this
> would limit the necessary number of characters.  But I do not think we can
> come up with an upper limit for years into the future that need to be
> represented.  Scientist (astronomers in particular) look far further into the
> future than 14 billion years.
> >
> > Anyway I would like your thoughts on this matter as the proposal will likely
> be submitted to TC154 and the Working Group will need to consider it.
> >
> > Ray
> >
> >
> >
> >
> >
> > > -----Original Message-----
> >
> > > From: Discussion of the Developing Date/Time Standards
> >
> > > [mailto:[log in to unmask]] On Behalf Of Christoph Päper
> >
> > > Sent: Friday, February 17, 2017 12:05 AM
> >
> > > To: [log in to unmask]
> >
> > > Subject: [DATETIME] Long Years in EDTF
> >
> > >
> >
> > > ISO 8601-2 is a “draft international standard” (DIS) right now, on ballot
> >
> > > through March. In section 4.5 it is specifying year-only dates which
> extend
> >
> > > beyond 4 digits without the need for further conventions, as proposed by
> >
> > > EDTF in <https://www.loc.gov/standards/datetime/pre-
> <https://www.loc.gov/standards/datetime/pre-
> submission.html#yearexceedingfourdigitsl1>
> >
> > >
> submission.html#yearexceedingfourdigitsl1<https://www.loc.gov/standards
> /datetime/pre-submission.html#yearexceedingfourdigitsl1>> (level 1) and
> >
> > > <https://www.loc.gov/standards/datetime/pre-
> <https://www.loc.gov/standards/datetime/pre-
> submission.html#yearexceedingfourdigitsexponentialform>
> >
> > >
> submission.html#yearexceedingfourdigitsexponentialform<https://www.loc
> .gov/standards/datetime/pre-
> submission.html#yearexceedingfourdigitsexponentialform>> (level 2,
> >
> > > exponential form). I believe this approach could be improved to be more
> >
> > > useful by documenting a existing pattern. I’m planning to also submit this
> >
> > > feedback through my national standards body (NSB).
> >
> > >
> >
> > > I agree that approximate years with many trailing zeros are clumsy.
> However,
> >
> > > the public seems to prefer to replace them by letters inspired by SI
> decimal
> >
> > > prefixes, instead of using exponential E notation: “Y2K” is a well known
> >
> > > alternative representation (in English) for the year 2000.
> >
> > >
> >
> > > ‘K’ conventionally stands for ‘kilo’, i.e. a multiple of 1000, a thousand.
> >
> > > Likewise, ‘M’ for ‘mega’ is a multiplier for a million and ‘G’ for ‘giga’
> multiplies
> >
> > > by a billion (or milliard). Since the age of the universe is estimated around
> 14
> >
> > > billion years and the remaining lifespan is perhaps in a similar order of
> >
> > > magnitude, larger multipliers – although defined in SI, e.g. ‘T’ for ‘tera’,
> >
> > > trillion – are not useful for years.
> >
> > >
> >
> > > The example used in EDTF/ISO, ‘y170000000’ = ‘Y17E7’, would therefore
> >
> > > become ‘Y170M’ or, perhaps, ‘Y0,17G’, ‘Y.17G’ …
> >
> > >
> >
> > > Also, the plus sign ‘+’ should be valid, though optional in positive years.
> >
> > > (Actually, with little changes to the standard, a mandatory prefixed sign
> could
> >
> > > replace the letter ‘Y’.)

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