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 2016

DATETIME April 2016

Subject:

Re: Section 4.9 One of a set.

From:

Nick Matthews <[log in to unmask]>

Reply-To:

[log in to unmask]

Date:

Sat, 2 Apr 2016 02:24:56 +0100

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (160 lines)

Hi Ray,

Primarily I was asking if I could transform the list without altering 
its meaning and, from your answer, it would appear yes, I can - which is 
good.

However, from the reply by Gerry, it appears precision needs to be 
preserved, which is not so good. For example [1667-12,1668] would not be 
the same as [1667-12..1668-12].

The calculator I'm working on is designed perform various functions on 
dates and date ranges. A primary function is to convert between 
different calendar schemes, but that is not relevant here. It can also 
perform set theory functions on the date ranges as in:

   1860 ~ 1880 \ ( 1865 | 1867 ~ 1869 )

in ISO level 2 format

Where ~ is used for range, \ is the relative complement operator 
(meaning 'and not') and | the union operator (which we can read as 'or').
  Which outputs:

   1860 ~ 1864 | 1866 | 1870 ~ 1880

in its native format.

Using ISO Level 2 format, it could be:

   [1860..1880] \ [1865,1867..1869]

and output:

  [1860..1864,1866,1870..1880]

Internally the years are first converted to Julian day numbers so the 
year 1865, for instance, is represented by the day numbers 2402238 ~ 
2402602 etc. After the calculation the resulting day numbers are 
converted back.

Initially, the numbers are converted to complete dates, but if the range 
starts on the first day, month and ends on the last day, month the 
output is trimmed to make it easier to read, no other reason, and could 
be switched off. It is because they are easier to read I tend to use 
just years in examples.

Nick

On 01/04/2016 9:01 PM, Denenberg, Ray wrote:
> Nick  - I'm not sure what you're asking.  If you have a list:
> [1668,1670..1672,1667]
>
> You might say that is can be normalized as  [1667..1668,1670..1672].
> But if you are asking whether only a normalized list is allowed, the
> answer is no.   A "best practices" document might recommend normalizing
> a list, and a profile certainly could.
>
> But again, I'm not sure if that's what you're asking.
>
> Even [..1800,1700..] (equivalent to [..])  is valid, and even though, as
> you note, it means the entire time continuum and could be difficult to
> deal with, that is not seen as sufficient reason to rule it out.
>
> As for precision ...
>
> When you say " /The fact that the internals are in days doesn't actually
> stop the output being years, if all the input is in years/" I'm not sure
> what you mean, could you give an example.
>
> You also mention “/I can't think of any practical use case for mixed
> precision/”
>
> The spec give the example:
>
> [1667,1760-12]  which means the event occurred e/ither during the year
> 1667 or the month December of 1760./
>
> /Whether that’s a //practical//example, I don’t know. (Someone thought
> it was.)/
>
> //
>
> /Ray///
>
>  > -----Original Message-----
>
>  > From: Discussion of the Developing Date/Time Standards
>
>  > [mailto:[log in to unmask]] On Behalf Of Nick Matthews
>
>  > Sent: Thursday, March 31, 2016 2:28 PM
>
>  > To: [log in to unmask] <mailto:[log in to unmask]>
>
>  > Subject: [DATETIME] Section 4.9 One of a set.
>
>  >
>
>  > Hi all,
>
>  >
>
>  > I'm implementing a historical calendar calculator and I would like to
> allow
>
>  > input and output in the format detailed in section 4.9.
>
>  >
>
>  > The calculator internally works in days and can output a list of date
> ranges.
>
>  > They are always in the form of, what I call, a "Well Ordered List"
> which means
>
>  > ranges do not overlap or abut one another and are in ascending order. The
>
>  > calculator would therefore treat the following as equivalent and only
> output the
>
>  > later:-
>
>  >
>
>  >    [1668,1670..1672,1667] == [1667..1668,1670..1672]
>
>  >
>
>  >    [..1760-12-03,1758..1761] == [..1761]
>
>  >
>
>  >    [..1800,1700..] == [..]
>
>  >
>
>  > Does this agrees with the intended use and if so, then maybe this
> could be
>
>  > explicitly stated.
>
>  >
>
>  > I imagine the last example [..] may be problematic (it means the
> entire time
>
>  > continuum) but it would be difficult to rule out the possibility of
> it arising so I
>
>  > have to deal with it.
>
>  >
>
>  > Nick
>
>  >
>
>  > http://historycal.org
>

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