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:

Monospaced Font

LISTSERV Archives

LISTSERV Archives

DATETIME Home

DATETIME Home

DATETIME  January 2018

DATETIME January 2018

Subject:

Re: Division of Year codes

From:

"Hostage, John" <[log in to unmask]>

Reply-To:

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

Date:

Tue, 9 Jan 2018 18:10:28 +0000

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (1 lines)

One reason for using codes for months and seasons is to represent them in a language-independent way. If we say 2018-01-09, that means the same thing around the world, disregarding time zone differences. Seasons can never be as unambiguous. If we say spring 2018, that's not the same thing in the Southern Hemisphere as in the Northern Hemisphere.

If we say winter 2018, some people in the Northern Hemisphere mean the season we're in now, while some others (some publications) might mean the season that begins next December. It's impossible to say what the codes "should" mean if we're trying to represent dates found on publications.

As I remember it, the codes 21-24 were chosen for seasons in EDTF because they were already being used in the MARC Format for Holdings Data (https://www.loc.gov/marc/holdings/hd853855.html) and nobody proposed a different standard to follow. It seems a bit late to make the codes more mnemonic, especially since that would mean making them more language dependent.

------------------------------------------
John Hostage


-----Original Message-----
From: Discussion of the Developing Date/Time Standards [mailto:[log in to unmask]] On Behalf Of Christoph P├Ąper
Sent: Tuesday, January 09, 2018 12:01
To: [log in to unmask]
Subject: Re: Division of Year codes

"Denenberg, Ray" <[log in to unmask]>:
>
> A year and a month within that year -- for example January 2018 -- takes the form YYYY-MM, as in 2018-01. In this sense a month is a division of a year. The division of a year concept introduced in the new version merely generalizes the year-month construct to apply to divisions beyond months. So a "division" other than month has to be represented by two-digits -- greater than 12 -- and 21 was chosen arbitrarily to begin the list.

I agree this far (notwithstanding my preference for letter prefixes).

> 'spring' was chosen to begin the list because it is the first season to begin within a year. Winter could just as easily have been chosen as the season in play when the year begins. The choice between spring and winter was arbitrary.

No, the choice was not arbitrary.

When ISO 2015, one of the predecessors of ISO 8601, was made, it needed to define a rule for the first week of the year. Although it is slightly couched in nebulous terms, the obvious underlying rule is that a week belongs to the year most of its days belong to. (With 7 days per week, it results in 4 January always being in the first week of the year. With Monday starting the week, this results in the first Thursday of the year always being in the first week of that same year.) This constitutes a convention that should be applied consistently in similar decisions. An astrological/astronomical season, namely Northern winter and Southern summer, therefore belongs to the year most of its days belong to, which is always the one it ends in and not the one it starts within.

Another concept of ISO 8601 date notation is that cyclic fields, i.e. all except for the year (or rather century) count, start at 1. (Time fields, however, start at 0, because they are traditionally counted more as cardinals than ordinals.)

> Does 01 for January have more meaning than 21 for Spring? Yes I suppose, but only marginally so.

If ISO only wanted and needed to support (astronomical) seasons, "21" (and not "20") would be a sound choice for Northern winter if you consider the arguments above. If ISO 8601-2 shall support other divisions of the year within the numeric MM field, "21" is _not_ a sound choice for any three-month or third-year season any more.

Humans intuitively look for meaning in the arbitrary first digit that is not an ordinal. The '2' should mean either "this subdivision is 2 months long" or "there are 2 of these subdivisions per year". Since there are 4 seasons of 3 months each, they would start with either '3' or '4'. Alas, quarter-years or trimesters and third-years or quadmesters are valid use cases as well and, at least by some definitions, match 3 and 4 whole consecutive months, respectively. Seasons would have to take one of whatever first digits remain. With 12*1 (months: 0x & 1x), 6*2 (bimesters, sixths: 2x), 4*3 (trimesters, quarters: 3x), 3*4 (quadmesters, thirds: 4x) and 2*6 (semesters, halves: 6x), this would be 5x, 7x, 8x or 9x. But if you also consider terms where the first one does not start with 1 January, but any other month, many of these will be occupied as well.

Like I said in my previous message, but did not emphasize before, it also makes total sense to limit the divisions that reuse the MM field to ones that contain whole months, seasons starting on the 21st-ish of a month should find a different solution. "S1" through "S4" seems reasonable. If you really wanted to get all traditional, you could argue instead in favor "S1" standing for Northern spring with "S0" for the winter that started in the year before and "S4" for the winter that ends in the year after.

> In any case, 8601 is intended to be machine processible. To the extent possible it is human readable, but that is not a primary objective.

Human readability has always been the primary objective for ISO date and time notation, but within a framework of unambiguous and logical constraints to achieve simple machine readability (and writeability). Otherwise we would not need formats with hyphens or colons at all.

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