Print

Print


Karin Bredenberg <[log in to unmask]>:
> 
> I agree with John I cant see the use case for all the added divisions and would prefer the original ones proposed.

I don’t have a huge problem with restricting EDTF / ISO 8601-2 (Level 1) to 4 vaguely defined seasons. I would just really hate if their codes were chosen in an arbitrary way that would make later, more systematic extensions impossible or needlessly awkward. I’ve provided an example of a systematic approach that would conflict with the proposed Level 2 codes:

>> 21-24 = Spring, Summer, Autumn, Winter, independent of “Hemisphere”
>> 25-28 = Spring - Northern Hemisphere, Summer- Northern Hemisphere, Autumn  - Northern Hemisphere, Winter - Northern Hemisphere 
>> 29-32 = Spring – Southern Hemisphere, Summer– Southern Hemisphere, Autumn – Southern Hemisphere, Winter - Southern Hemisphere 
>> 33-36 = Quarter 1, Quarter 2, Quarter 3, Quarter 4 (3 months  each)
>> 37-39 = Quadrimester 1, Quadrimester 2, Quadrimester 3  (4 months each)
>> 40-41 = Semestral 1, Semestral-2 (6 months each)

It’s true that for bibliographic and genealogical purposes one usually can not and need not identify an exact definition for Spring, Summer, Fall/Autumn and Winter (or terms like Monsoon Season etc. used elsewhere). It’s usually possible to determine whether N-Winter / S-Summer or N-Spring / S-Autumn is considered the first season of the Gregorian year, however. That is something the codes should reflect. 

I can only imagine a single, exotic use case for codes `21`…`24` as defined in the DIS (paraphrased by John Hostage above): when the user doesn’t know which hemisphere applies. That is not very useful in calendar applications at all. It surely should not be the default.

Level 1 should have 4 codes, for the first, second, third and fourth quarter of the year, which may be called “seasons”. Using the currently drafted codes, this would mean

  - `-21` Northern Winter or Spring = Southern Summer or Autumn
  - `-22` Northern Spring or Summer = Southern Autumn or Winter
  - `-23` Northern Summer or Autumn = Southern Winter or Spring
  - `-24` Northern Autumn or Winter = Southern Spring or Summer

Paving cowpaths – especially from economics – found in the real world, the codes `Q1`…`Q4` would be more appropriate. They follow the syntax convention established by week dates `W01`…`W53`.

For less ambiguity, it *may* make sense to add a “zero variant” covering the previous year:

  - `-20` = `-Q0` Northern Winter = Southern Summer – ranging into the previous year
  - `-21` = `-Q1` Northern Spring = Southern Autumn
  - `-22` = `-Q2` Northern Summer = Southern Winter
  - `-23` = `-Q3` Northern Autumn = Southern Spring
  - `-24` = `-Q4` Northern Winter = Southern Summer – ranging into the next year

These quarter-years may be equivalent to 3 complete consecutive months (MM) or 13+ weeks (wWW) or 91+ days (DDD), but they would not have to be, i.e. they could just as well start at or be centered at the (actual astronomic or nominal arithmetic) equinoxes and solstices. Similarly, if you used ISO 8601 week notation for weekly periodicals in a bibliographic setting, you would have to ignore the actual day of the week they are (usually) released, because ISO weeks always start Monday. (For a non-academic example, all print TV guides I’ve ever seen in Europe start their week at Saturday and are released one to several days before.)

If we left the ‘Q’ codes to Level 1, Level 2 could adopt a more complete (numeric) set like the ones I described in previous mails in this thread. Sometimes users do know better or may set themselves the definition of a seasonal term used in their application and they should not have to resort to <start>/<duration> or <start>/<end> period notation for that.

I really very much prefer the marker letter approach (‘Q’ in this case), as evidenced by the many formats described in <https://calendars.wikia.com/wiki/International_Calendar> – not all of which I would consider crucial. It is much more intuitive to humans and not more language-dependent than letters already established in ISO 8601. Existing parsers would, of course, reject dates like “2017-Q1” (or even “2017-Q1-70”) as *malformed*, whereas they should reject dates like “2017-21” (or “2017-21-70”) as *invalid* (i.e. it seemed to be CCYY-MM but wasn’t) – the difference is perhaps negligible in practice.

I’ve seen nothing yet that would cover periodicals issued biweekly (“fortnightly”) or twice a month, by the way, although that is somewhat common.