Quarter depends on reporting periods, or fiscal year, which does not match calendar year everywhere.

  > which does not match calendar year everywhere

Yes, this is the reason that ISO-8601 ranges are not sufficient and a Quarter indicator is necessary.

The problem is that if you carry the string '2021-Q1' across countries borders, the days it represents change. That makes for a very bad time interchange format.

I agree that this feature makes quarter indicator necessary. But it also makes it required that the string is something more complex.

If you carry the string '2021-10-24' across countries borders, the moments in time that it represents change as well.

That makes doesn't make it a bad time interchange format for certain use cases, though. Just like everything else with time, one must be aware of caveats. Those include timezones, leap periods, culture, DST, formats, legislation (modern and ancient), etc.

But it overlaps. It's off, but less than 100% off.

"2021-Q1" can be a completely different and non-overlapping range between regions, and even between companies in the same region.

2021-10-24 in UTC+14 (Line Islands) and UTC-10 (Hawaii) are, in fact, 100% off.

Yeah the Line Islands are the exception as always.

We could've gone with most of New Zealand (UTC+13 summer time) and any of the US territories in UTC-11. These are marginal cases, not exceptional ones.

Fine, they overlap with the UTC day. They are less than 100% compared to the UTC day, even if they can be 100% off with each other.

ISO 8601-2:2019 defines quarters in section 4.8, "Sub-year groupings". Your example of "2021-Q1" can be represented as "2021-33".

Unfortunately the document is not freely available. Can you elaborate how it works?

The latest standard (2019) is divided into two parts: ISO 8601-1 and ISO 8601-2. Part 2 is titled "Extensions" and includes many different - but optional - ways to extend representations of dates and times. In my opinion, Part 2 represents the "leftovers" - that which was too domain specific or esoteric to warrant broad implementation.

Representations of seasons, quarters, etc. is one of many types of extensions included in Part 2.

These extensions are always used in "YYYY-MM" format (and always include the "-"). For the "MM" field, you use the numbers 21-41 inclusive. The numbers represent, in order, spring, summer, autumn, and winter, in 3 ways: independent of hemisphere (21-24), northern hemisphere specifically (25-28), southern hemisphere specifically (29-32); quarters 1-4 (33-36), quadrimesters 1-3 (37-39), and finally, semestrals 1-2 (40-41).

This, in combination with the fact that the lookup table is paywalled, makes it a great competitor for the "extremely pointlessly overengineered standards" award.

I wonder if there is any software that actually supports that.

Where's the 33 come from?

There is a list of "Sub-year groupings" which assign two-digit numbers to seasons (hemisphere independent), seasons (Northern Hemisphere), seasons (Southern Hemisphere), quarters, quadrimesters (four-month periods), and semestrals (six-month periods). The numbering starts at 21.

The numbers 1 to 12 are already used to represent months in formats such as YYYY-MM, so starting this list higher than 12 allows these (certainly rare) representations to coexist. e.g. "2021-12" represents "October, 2021" and "2021-29" represents "Spring, Southern Hemisphere, 2021".