cmclaren

I spent some time in SE Asia. Plastic consumption is rampant there, with styrofoam trays, plastic wrap, and plastic bags used for most items in stores. Street food vendors put their food in plastic. Straws and hard plastic cups are commonplace. Litter is common and waste management is nonexistent in many areas.

One problem I’ve noticed there is the high volume of single-use plastic water bottles in use to deliver potable water. Most water is not drinkable from the tap, so this is the solution.

Ensuring country-wide safe drinking water from the tap is no small feat, so this is incredibly discouraging.

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

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

By default, ISO 8601-1:2019 does not permit negative years in date representations.

Expanded representation (i.e. five digits or more for the year) permits both positive and negative years (and the sign is mandatory for both positive and negative years).

ISO 8601-2:2019 has provisions for numeric extensions. Subclause 4.4.1.2 permits negative four-digit years (years -9999 to -0001).

Note that both of these options require mutual agreement.

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

Your example is valid in ISO 8601-1:2019.

There are only two possible representations for which "T" is required: hh or hhmm in 'basic' format (i.e. no ":" separator). The former could be confused with a two-digit century, the latter could be confused with a four-digit year. Adding "T" to hh or hhmm solves this.

Any of the following eliminates the "risk of confusion":

  - 'extended' format (hh:mm)
  - decimal fraction (hhmm,m or hh,h; see 5.3.1.4);
  - UTC designator (hhmmZ or hhZ; see 5.3.3), or;
  - time shift (hhmm±hhmm, hhmm±hh, hh±hhmm, or hh±hh; see 5.3.4).

Also worth noting: hhmmss in 'basic' format (i.e. no ":" separator) does not pose a risk of confusion, as YYYYMM in 'basic' format (i.e. no "-" separator) is not permitted by the spec.

The spec permits more than 4 digits for 'year' by mutual agreement. This is called 'expanded representation'. There is no limit to the number of digits, but parties need to agree on how many additional digits will be used to avoid ambiguous representations.

Consider that +002021001 could represent:

a) "Oct 1, 202" as a calendar date (proleptic Gregorian), in 'basic' format (i.e. no "-" separator), 5 digits for year.

b) "Jan 1, 2021" as an ordinal date, 'basic' format (i.e. no "-" separator), 6 digits for year.

I encountered this problem a number of times. I believe, in my case at least, that I noticed a pattern. I believe that facebook's activity log filters posts related to disabled accounts.

I think that when someone decides to re-enable their disabled account, your posts related to their account re-appear in your activity log. Therefore, one can never be sure if all activity is deleted, and one must iteratively return to the activity log every so often to delete re-appearing posts.