Print

Print


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.  '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.  

Does 01 for January have more meaning than 21 for Spring?  Yes I suppose, but only marginally so.  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.

Ray

> -----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 8:51 AM
> To: [log in to unmask]
> Subject: Re: [DATETIME] Division of Year codes
> 
> Tony Benedetti <[log in to unmask]>:
> >
> > 2. The real problem is that the codes for the other divisions provide no
> mnemonic value to a human user while either constructing or deciphering a
> date "by hand".
> > 3. I believe that the codes for the remaining divisions (half, third, quarter and
> season) should suggest (as a mnemonic measure) the type of division to a
> human user.
> 
> All your points are valid and I share them. Actually, I have send similar notes to
> this list and to my NSB last year, ending up with similar but slightly different
> codes:
> 
>   <https://listserv.loc.gov/cgi-bin/wa?A2=ind1702&L=DATETIME&P=61>
> through <https://listserv.loc.gov/cgi-bin/wa?A2=ind1703&L=DATETIME&P=58>
> 
> I still prefer letter prefixes like "W" for "week", though, because at least "Q" for
> "quarter (year)" is already established in many places.
> 
> > 4. Omission of a "Northern/Southern" qualifier for the seasons can lead to
> confusion (or worse, inaccuracy).
> 
> For dating publications, it probably does not matter at all, but we have multiple
> definitions for the start of seasons, too: Astrological seasons begin at the the
> equinoxes and solstices, thus align with the tropical zodiac, whereas cultural or
> meteorological seasons in some places start on the 1st of the respective
> months or have the Sun's extreme points in the middle of the seasons. Many
> places closer to the equator do not recognize four seasons or their seasons are
> of uneven lengths.
> 
> If reusing and overloading the month field MM, it makes some sense to have
> all additional periods cover full months, i.e. astronomical seasons would not
> qualify.
> 
> For seasons in particular, there is the issue which one should be the first of the
> year. Traditionally, the astronomical year begins with the March equinox and
> thus (Northern) spring, but (ever since the start of the year was shifted to
> January) the majority of (Northern) winter lies within the later year and
> reapplying the Thursday rule from ISO weeks, winter should therefore be the
> first season of the year. Either way, years would get a third meaning in ISO
> 8601:
> 
> 1. 12 months or 365 (366) days, starting -01-01 (1 January) 2. 52 (53) weeks or
> 364 (371) days, starting -W01-1 3. 4 seasons or 365 (366) days, starting ??
> 
> > 5. The terminology for the divisions in section 4.7.2 should also be revised.
> The currently used nomenclature is a mixture of both common and more
> "academic" terms.  In addition, the terms are an inconsistent mix of nouns and
> adjectives.
> 
> Note that "semester" and "semestral" do not derive from "semi" for "half
> (year)" but from the Latin for "six months". In a pregnancy, a "trimester" is
> both, 3 months and a third of the full term, and in academics it may
> approximate both. Anyway, unless they are used to inform letter codes like "Q"
> mentioned above, the actual terminology used in the standard is of little
> consequence for most of its users, but I agree it should be as unambiguous and
> consistent as possible.