LISTSERV mailing list manager LISTSERV 16.0

Help for DATETIME Archives


DATETIME Archives

DATETIME Archives


[email protected]


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  January 2018

DATETIME January 2018

Subject:

Re: Seasons in intervals (ISO 8601)

From:

Christoph Päper <[log in to unmask]>

Reply-To:

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

Date:

Thu, 18 Jan 2018 00:10:23 +0100

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (72 lines)

>> Denenberg, Ray:
>>>
>>> If [seasons in intervals] is to be added it would be with the restriction that if a season is supplied in one part of an interval then a season must be supplied in the other part.
>>> (Or more generally, they must both be in the same division class.) 

Whether this restriction would be sensible depends on how specific seasons are to be specified in ISO 8601.

>>> Further, clarification will  be added that a season is associated
>>> with the year in which it begins.

This would be inconsistent with how calendar weeks are defined by ISO. W01 is not the one with the first Monday of the year but the one with the first Thursday of the year! (In 2018 -W01-1 and -01-01 coincided, so the question of first week was trivial to decide.)

>>> The latter pertains specifically to winter: we are currently in winter 2017, not winter 2018.

By all conventions set forth by ISO 8601 until now, we are not (unless this "winter" is a period from, e.g., 1 November through 31 January).

You are obviously assuming an astronomical definition of seasons. This needs to be settled and stated in the standard. I strongly believe extensions to the MM field should be restricted to divisions that contain whole calendar months, which incidentally includes European meteorological definitions of the seasons. Introduce 'S1' through 'S4' or something else for astronomical seasons. Some academic trimesters and fiscal quarters (and other divisions) also use descriptive terms like "winter", but often agree with neither the meteorological nor the astronomical definition of seasons. EDTF may have been developed for bibliographic purposes where the astronomical, Northern-hemispheric definition predominates, but ISO 8601 has a much broader scope.

>>> This may cause discomfort because although this is the commonly accepted definition 

ISO 8601 does not need to comply with external sources if that would break internal consistency. The whole point of a standard is to select a single definition for ambiguous terms.

----

> Hostage, John <[log in to unmask]> wrote:
> 
>> I think there are two conflicting understandings of seasons at work here.

There are indeed.

>> One tries to nail down a precise definition that can be validated and manipulated mathematically.

This is the definition that would accommodate existing ISO 8601 practice.

>> The other realizes that seasons are bound up with language, culture, and the part of the world being talked about.

This one is what librarians and others involved with bibliographies would prefer apparently.

>> Maybe it’s futile to include seasons in a date and time standard because they are so subjective.

The beauty of a standard is that it can settle on a single definition that is most consistent with other definitions used in that standard.

>> It seems like a non-starter to say that if a publisher calls something “winter 2018” we have to represent it as 2017-24.

The current, cumbersome way would be, for instance, "2017-12/2018-02". You also have to translate natural language terms like "January" or "Monday" or "afternoon"; seasons are just a bit harder.

>> And if an issue says “winter 2017” we won’t know if that means 2017-24 under that definition or 2016-24, unless perhaps we have a lot of adjacent numbered issues to compare it to.

That is reason enough not to encode it in a ISO-8601 date notation, in my humble opinion..

----

Stephen Hearn <[log in to unmask]>:
> 
> It might be simpler to dispense with specific seasonal terms 
> and just authorize a relative sequence specified by year:

Indeed. Month names are also only informative, not normative in ISO 8601.

> The defined values could be extended to cover cases where a year is divided
> into more than four "seasons" or non-month units.

That is why it has been suggested to use the first digit semantically (as far as possible): Let it designate either the number of months in each division or the number of such divisions per year. Four seasons (=> quarters) of (about) three months each (=> trimesters) would thus preferably run from either 31 through 34 or from 41 through 44. 

If the first division should (optionally) not start with 1 January, things get more complicated and weird. The earliest first day of a max. 91-day first season should be 18 October of the preceding year and the latest first day of that season should be 15 February, which would ensure that the majority of the days in the season is in the year their season nominally belongs to. This would be consistent with how ISO 8601 defines the first week of the year, i.e. the one with at least 4 out of 7 days within that year.

> The particular terms to be used for each serial's issue designations would
> have to be recorded some other way, as arguably they should be given the
> idiosyncratic nature of such term use.

I completely agree. This is how ISO date standards have worked for decades.

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

March 2022
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