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