Re: CALNDR-L Digest - 29 Jul 2016 to 10 Aug 2016 (#2016-175)

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: CALNDR-L Digest - 29 Jul 2016 to 10 Aug 2016 (#2016-175)

John Dalziel
I know one of the items under consideration is EDTF. 

The list for the group is here


John Dalziel

On 10 August 02016 at 21:00:02, CALNDR-L automatic digest system ([hidden email]) wrote:

There is 1 message totaling 45 lines in this issue.

Topics of the day:

1. ISO 8601 under review
Fellow calendarists

Did you know that ISO 8601, last updated in 2004, is currently under review by ISO/TC 154?

It seems it will be split into two parts:

* ISO 8601-1: Data elements and interchange formats --
Information interchange --
Representation of dates and times --
Part 1: Basic rules
* ISO 8601-2: Part 2: Extensions

They are currently Committee Drafts (CD) in the 30.20 phase “CD study/ballot initiated”.

* http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?ics1=01&ics2=140&ics3=30&csnumber=70907
* http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?ics1=01&ics2=140&ics3=30&csnumber=70908

I wish I knew what was going on and whether or how it was possible to provide some input to the standardization, e.g. to get official quarter notation, dash/colon separators as default form, the extension of the Thursday rule to months and *some* of the other things I’ve done in <http://calendars.wikia.com/wiki/International_Calendar>.

Previous updates of the standard brought some major changes, especially for truncated date formats.

Cheers

Christoph
Reply | Threaded
Open this post in threaded view
|

Re: CALNDR-L Digest - 29 Jul 2016 to 10 Aug 2016 (#2016-175)

Christoph Päper-2
John Dalziel - crashposition <[hidden email]>:
>
> I know one of the items under consideration is EDTF.
> https://www.loc.gov/standards/datetime/

Thank you! I didn’t know about EDTF and I have tried to look for projects like this before I started work on the International Calendar. Very interesting.

One major difference seems to be that I embrace the ‘W’ of the week notation and adopt it for quarters etc. (‘Q’, ‘S’), whereas EDTF chooses numeric dates. It uses letters, additional punctuation marks and even words in other places, though.
Reply | Threaded
Open this post in threaded view
|

Futile - First things First Re: CALNDR-L Digest - 29 Jul 2016 to 10 Aug 2016 (#2016-175)

Brij Bhushan metric VIJ
In reply to this post by John Dalziel
John Daiziel, Christoph sits:
While I take the courage to recall my input through Preperatory draft in ISO:1975 (R), there has not been enough publicity/effort to reach a common implementation for Information interchange - Representation for date and time expression; a Revision by ISO/TC 154 or the like may not reach anywhere near the 'ideals for Reform of the Gregorian calendar' under efforts of World Calendar Organisation. I congratulate John, sir for showing concern. Need therefore is far greater than mere Standardising and producing yet another 'Standard' but it needs direction to decide a NORMALISED reform for corrections to currently used Gregorian calendar, some ideals of my discussions have remained under examination: http://www.brijvij.com/ as the Easiest, Surest and Cheapest 'EVER' proposal merely by "shifting the day of July 31 to 2nd month as February 29 (all years) and place the LeapDay between June 30 and July 01 modifying the LeapDay Rule to divide 4/skip128th-years improving the Mean Year =365.2421875 days =(365+31/128) Days. 
Same Mean Year value results on following Divide 6, Leap Weeks, using 7*128 ie 896-years, with Mean Year=7*(52+159/896) days or 7*(52+1/6+29/2688) days, closer to actual Astronomers Average Mean Year of 365.242189669781 days. Alternately, my developed 834-year cycle provides the 'best possible' mean year closer to Tropical year, as discussed with Calndr-L experts since my joining around mid-2002.
Be kind to refer to archives or visit my 'web site': 
My regards to all members,
Brij Bhushan (metric) VIJ
Thursday, 2016 August 10H16:15(decimal)


Sent from my iPhone

On Aug 10, 2016, at 1:10 PM, John Dalziel - crashposition <[hidden email]> wrote:

I know one of the items under consideration is EDTF. 

The list for the group is here


John Dalziel

On 10 August 02016 at 21:00:02, CALNDR-L automatic digest system ([hidden email]) wrote:

There is 1 message totaling 45 lines in this issue.

Topics of the day:

1. ISO 8601 under review
Fellow calendarists

Did you know that ISO 8601, last updated in 2004, is currently under review by ISO/TC 154?

It seems it will be split into two parts:

* ISO 8601-1: Data elements and interchange formats --
Information interchange --
Representation of dates and times --
Part 1: Basic rules
* ISO 8601-2: Part 2: Extensions

They are currently Committee Drafts (CD) in the 30.20 phase “CD study/ballot initiated”.

* http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?ics1=01&ics2=140&ics3=30&csnumber=70907
* http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?ics1=01&ics2=140&ics3=30&csnumber=70908

I wish I knew what was going on and whether or how it was possible to provide some input to the standardization, e.g. to get official quarter notation, dash/colon separators as default form, the extension of the Thursday rule to months and *some* of the other things I’ve done in <http://calendars.wikia.com/wiki/International_Calendar>.

Previous updates of the standard brought some major changes, especially for truncated date formats.

Cheers

Christoph
Reply | Threaded
Open this post in threaded view
|

Re: CALNDR-L Digest - 29 Jul 2016 to 10 Aug 2016 (#2016-175)

Karl Palmen
In reply to this post by John Dalziel

Dear John, Christoph and Calendar People

 

I’ve had a brief look at the proposed extension and it has ways of expressing an uncertain date such as

year known to be 2004 month uncertain but probably June and day of month 11, which would be expressed as 2004-(06)?-11.

 

This makes non-support of non-Gregorian calendars a more serious issue. Conversion to such an extension from similar in a non-Gregorian calendar would be complicated and may be impossible and if possible the resulting date could be long and hard to read. So it might be better to express such dates in the calendar of the source rather than force it to expressed in Gregorian.

 

Karl

 

15(15(13

 

From: East Carolina University Calendar discussion List [mailto:[hidden email]] On Behalf Of John Dalziel - crashposition
Sent: 10 August 2016 21:11
To: [hidden email]
Subject: Re: CALNDR-L Digest - 29 Jul 2016 to 10 Aug 2016 (#2016-175)

 

I know one of the items under consideration is EDTF. 

 

The list for the group is here

 

 

John Dalziel

 

On 10 August 02016 at 21:00:02, CALNDR-L automatic digest system ([hidden email]) wrote:

There is 1 message totaling 45 lines in this issue.

Topics of the day:

1. ISO 8601 under review
Fellow calendarists

Did you know that ISO 8601, last updated in 2004, is currently under review by ISO/TC 154?

It seems it will be split into two parts:

* ISO 8601-1: Data elements and interchange formats --
Information interchange --
Representation of dates and times --
Part 1: Basic rules
* ISO 8601-2: Part 2: Extensions

They are currently Committee Drafts (CD) in the 30.20 phase “CD study/ballot initiated”.

* http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?ics1=01&ics2=140&ics3=30&csnumber=70907
* http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?ics1=01&ics2=140&ics3=30&csnumber=70908

I wish I knew what was going on and whether or how it was possible to provide some input to the standardization, e.g. to get official quarter notation, dash/colon separators as default form, the extension of the Thursday rule to months and *some* of the other things I’ve done in <http://calendars.wikia.com/wiki/International_Calendar>.

Previous updates of the standard brought some major changes, especially for truncated date formats.

Cheers

Christoph

Reply | Threaded
Open this post in threaded view
|

EDTF in ISO 8601-2 was: CALNDR-L Digest - 29 Jul 2016 to 10 Aug 2016 (#2016-175)

Christoph Päper-2
In reply to this post by Christoph Päper-2
Christoph Päper <[hidden email]>:
> John Dalziel - crashposition <[hidden email]>:
>>
>> I know one of the items under consideration is EDTF.
>> https://www.loc.gov/standards/datetime/

This contributes most of the draft new Part 2 of ISO 8601, whereas ISO 8601-1:2016 or :2017 will be almost the same as the whole of ISO 8601:2004. (Disclaimer: I’ve only seen drafts from early 2016.)

- <http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber=70907>
- <http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber=70908>

NB: If someone had access to the latest drafts and could share them with me, I would be most grateful.

> One major difference seems to be that I embrace the ‘W’ of the week notation and adopt it for quarters etc. (‘Q’, ‘S’), whereas EDTF chooses numeric dates.

EDTF proposes -21, -22, -23 and -24 to use for the seasons (Northern/local) spring through winter, which are not defined in more detail. That may fit well with its focus on fuzzy dates (low precision or accuracy), but is unsatisfactory otherwise. I don’t like much the idea to overload CCYY-MM syntax with CCYY-SS, but it’s also been suggested to add notation for 2-, 4- and 6-month intervals, possibly with different start dates.

I reckon that the two digit-number (1–6) could be composed as

 - <ordinal><seasons-per-year>
 - <ordinal><months-per-season>

but these don’t work. For the first one, 6-month semesters would have values ‘11’ and ‘12’. For the second one, the initial 2-month bimester value would be ‘12’. These are obviously already occupied by the months (November and) December. Thus, for consistency, we’re left with these “big-endian” options:

 - <seasons-per-year><ordinal>    =: “S/Y”
 - <months-per-season><ordinal>   =: “M/S”

For 2-month bimesters, 3-month trimesters, 4-month quadmesters and 6-month semesters, this leads to these values for the default case:

  Term           S/Y     M/S   Sets Months Weeks Days
  bimesters: ‘61’…‘66’ ‘21’…‘26’ 2   2 9–10 59– 62
  trimesters: ‘41’…‘44’ ‘31’…‘34’ 3–4 3 13–14 89– 92
  quadmesters: ‘31’…‘33’ ‘41’…‘43’ 4   4 17–18 120–123
  semesters: ‘21’/‘22’ ‘61’/‘62’ 6–8 6 26–27 181–184

However, since there certainly are applications for each term length to start with any month, these would require multiple sets of full months. A useful standard perhaps should also add 1 trimester-like set for astronomic seasons and 2 semester-like sets for astronomic “demiyears” (i.e. one equinox-based, one solstice-based). Similar to naked year numbers, it can be left as ambiguous – unless more precise dates are specified – whether these are actually month-based (includes day-based) or week-based.

It makes some sense to think of the possible notations as contractions of either <months-per-season> × <ordinal> or <ordinal> / <seasons-per-year>. Since we’ve already determined that the ordinal digit shall come second, only one of the two remaining options makes sense, which has also better string and numeric sort/collation behavior for most cases:

 - <months-per-season><ordinal>

Some digits are obviously not used for the default sets (including single months) where the first term starts with (or is) January.

  Unused first digits: 5, 7, 8, 9
  Unused last digits: 0, 7, 8, 9 (except for 0 or 1 as first digit, i.e. single months)

The values ‘00’ and ‘13’…‘19’ should be avoided for meaning any timespan considerable shorter or longer than a single month, in my humble opinion.

Based on these observations, ISO 8601(-2) could define two-digit codes for several month-based timespans.

Bimesters
=========

2 months each; usually 9 weeks, sometimes 8 weeks, never 10 weeks.

 - default set: 2x (offset ±0)
 - additional set: 7x

        JanFeb   21   FebMar  71
        MarApr   22   AprMay  72
        MayJun   23   JunJul  73
        JulAug   24   AugSep  74
        SepOct   25   OctNov  75
        NovDec   26   DecJan  76

If it was desirable that FebMar be sorted between JanFeb and MarApr, these 12 terms overall would still require 2 different digits in the first code place, e.g. odd digits for the default set and even ones for the alternative set. It seems reasonable to ignore this desire for the other term lengths as well then. (I tried, it’s too confusing for humans.)

Trimesters
==========

3 months each; usually 13 weeks, sometimes 14 weeks, rarely – if ever – 12 weeks. Also well known as “quarters”.

 - default set: 3x (offset ±0)
 - additional sets: 3x, 8x
 - unused:         30

 Offset: ±0
 ----------

  JanFebMar     31
  AprMayJun     32
  JulAugSep     33
  OctNovDec     34

 Offset: +1
 ----------

  FebMarApr   36
  MayJunJul   37
  AugSepOct   38
  NovDecJan   39=35

 Offset: –1
 ----------

  DecJanFeb     80=84 81=85
  MarAprMay 81 82
  JunJulAug 82 83
  SepOctNov 83 84

 Offset: –astronomic
 -------------------

  N-Winter   85=89
  N-Spring   86
  N-Summer   87
  N-Fall     88

Quadmesters
===========

4 months; 17 or 18 weeks.

 - default set: 4x (offset ±0)
 - additional sets: 4x, 9x
 - unused:         40, 44, 45, 94, 95

 Offset: –1
 ----------

  DecJanFebMar  96=99
  AprMayJunJul 97
  AugSepOctNov 98

 Offset: ±0
 ----------

  JanFebMarApr  41
  MayJunJulAug  42
  SepOctNovDec  43

 Offset: +1
 ----------

  FebMarAprMay  91
  JunJulAugSep  92
  OctNovDecJan  93=90

 Offset: ±2
 ----------

  MarAprMayJun  47
  JulAugSepOct  48
  NovDecJanFeb  49=46

Semesters
=========

6 months; 26 weeks, sometimes 27 weeks.

 - default set: 6x (offset ±0)
 - additional sets: 6x, 5x (or 7x)

 Offset: –2
 ----------
  NovDecJanFebMarApr     54
  MayJunJulAugSepOct   55=53

 Offset: –1
 ----------
  DecJanFebMarAprMay     57
  JunJulAugSepOctNov 58=56

  Solstice–Solstice 1 70?
  Solstice–Solstice 2 71?

 Offset: ±0
 ----------
  JanFebMarAprMayJun     61
  JulAugSepOctNovDec   62

 Offset: +1
 ----------
  FebMarAprMayJunJul     64
  AugSepOctNovDecJan 65=63

 Offset: +2
 ----------
  MarAprMayJunJulAug     67
  SepOctNovDecJanFeb     68=66

  North–Southward Equinox 60?
  South–Northward Equinox 69?

 Offset: ±3
 ----------
  AprMayJunJulAugSep     51
  OctNovDecJanFebMar     52=50

Offsets +2/–4 and ±3 are quite common in education and academics.
Reply | Threaded
Open this post in threaded view
|

Re: EDTF in ISO 8601-2 was: CALNDR-L Digest - 29 Jul 2016 to 10 Aug 2016 (#2016-175)

Karl Palmen
Dear Christoph and Calendar People

I've read this several months ago and pointed out that this extension makes the non-support of non-Gregorian calendars a more important issue, because the fuzzy dates proposed do not convert easily between calendars and are so are best expressed in their source calendar.

One exception to this are full date ranges such as 2016-12-05/2016-12-25.

Karl

16(04(06

-----Original Message-----
From: East Carolina University Calendar discussion List [mailto:[hidden email]] On Behalf Of Christoph Päper
Sent: 05 December 2016 14:17
To: [hidden email]
Subject: EDTF in ISO 8601-2 was: CALNDR-L Digest - 29 Jul 2016 to 10 Aug 2016 (#2016-175)

Christoph Päper <[hidden email]>:
> John Dalziel - crashposition <[hidden email]>:
>>
>> I know one of the items under consideration is EDTF.
>> https://www.loc.gov/standards/datetime/

This contributes most of the draft new Part 2 of ISO 8601, whereas ISO 8601-1:2016 or :2017 will be almost the same as the whole of ISO 8601:2004. (Disclaimer: I’ve only seen drafts from early 2016.)

- <http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber=70907>
- <http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber=70908>

NB: If someone had access to the latest drafts and could share them with me, I would be most grateful.

> One major difference seems to be that I embrace the ‘W’ of the week notation and adopt it for quarters etc. (‘Q’, ‘S’), whereas EDTF chooses numeric dates.

EDTF proposes -21, -22, -23 and -24 to use for the seasons (Northern/local) spring through winter, which are not defined in more detail. That may fit well with its focus on fuzzy dates (low precision or accuracy), but is unsatisfactory otherwise. I don’t like much the idea to overload CCYY-MM syntax with CCYY-SS, but it’s also been suggested to add notation for 2-, 4- and 6-month intervals, possibly with different start dates.

I reckon that the two digit-number (1–6) could be composed as

 - <ordinal><seasons-per-year>
 - <ordinal><months-per-season>

but these don’t work. For the first one, 6-month semesters would have values ‘11’ and ‘12’. For the second one, the initial 2-month bimester value would be ‘12’. These are obviously already occupied by the months (November and) December. Thus, for consistency, we’re left with these “big-endian” options:

 - <seasons-per-year><ordinal>    =: “S/Y”
 - <months-per-season><ordinal>   =: “M/S”

For 2-month bimesters, 3-month trimesters, 4-month quadmesters and 6-month semesters, this leads to these values for the default case:

  Term           S/Y     M/S   Sets Months Weeks Days
  bimesters: ‘61’…‘66’ ‘21’…‘26’ 2   2 9–10 59– 62
  trimesters: ‘41’…‘44’ ‘31’…‘34’ 3–4 3 13–14 89– 92
  quadmesters: ‘31’…‘33’ ‘41’…‘43’ 4   4 17–18 120–123
  semesters: ‘21’/‘22’ ‘61’/‘62’ 6–8 6 26–27 181–184

However, since there certainly are applications for each term length to start with any month, these would require multiple sets of full months. A useful standard perhaps should also add 1 trimester-like set for astronomic seasons and 2 semester-like sets for astronomic “demiyears” (i.e. one equinox-based, one solstice-based). Similar to naked year numbers, it can be left as ambiguous – unless more precise dates are specified – whether these are actually month-based (includes day-based) or week-based.

It makes some sense to think of the possible notations as contractions of either <months-per-season> × <ordinal> or <ordinal> / <seasons-per-year>. Since we’ve already determined that the ordinal digit shall come second, only one of the two remaining options makes sense, which has also better string and numeric sort/collation behavior for most cases:

 - <months-per-season><ordinal>

Some digits are obviously not used for the default sets (including single months) where the first term starts with (or is) January.

  Unused first digits: 5, 7, 8, 9
  Unused last digits: 0, 7, 8, 9 (except for 0 or 1 as first digit, i.e. single months)

The values ‘00’ and ‘13’…‘19’ should be avoided for meaning any timespan considerable shorter or longer than a single month, in my humble opinion.

Based on these observations, ISO 8601(-2) could define two-digit codes for several month-based timespans.

Bimesters
=========

2 months each; usually 9 weeks, sometimes 8 weeks, never 10 weeks.

 - default set: 2x (offset ±0)
 - additional set: 7x

        JanFeb   21   FebMar  71
        MarApr   22   AprMay  72
        MayJun   23   JunJul  73
        JulAug   24   AugSep  74
        SepOct   25   OctNov  75
        NovDec   26   DecJan  76

If it was desirable that FebMar be sorted between JanFeb and MarApr, these 12 terms overall would still require 2 different digits in the first code place, e.g. odd digits for the default set and even ones for the alternative set. It seems reasonable to ignore this desire for the other term lengths as well then. (I tried, it’s too confusing for humans.)

Trimesters
==========

3 months each; usually 13 weeks, sometimes 14 weeks, rarely – if ever – 12 weeks. Also well known as “quarters”.

 - default set: 3x (offset ±0)
 - additional sets: 3x, 8x
 - unused:         30

 Offset: ±0
 ----------

  JanFebMar     31
  AprMayJun     32
  JulAugSep     33
  OctNovDec     34

 Offset: +1
 ----------

  FebMarApr   36
  MayJunJul   37
  AugSepOct   38
  NovDecJan   39=35

 Offset: –1
 ----------

  DecJanFeb     80=84 81=85
  MarAprMay 81 82
  JunJulAug 82 83
  SepOctNov 83 84

 Offset: –astronomic
 -------------------

  N-Winter   85=89
  N-Spring   86
  N-Summer   87
  N-Fall     88

Quadmesters
===========

4 months; 17 or 18 weeks.

 - default set: 4x (offset ±0)
 - additional sets: 4x, 9x
 - unused:         40, 44, 45, 94, 95

 Offset: –1
 ----------

  DecJanFebMar  96=99
  AprMayJunJul 97
  AugSepOctNov 98

 Offset: ±0
 ----------

  JanFebMarApr  41
  MayJunJulAug  42
  SepOctNovDec  43

 Offset: +1
 ----------

  FebMarAprMay  91
  JunJulAugSep  92
  OctNovDecJan  93=90

 Offset: ±2
 ----------

  MarAprMayJun  47
  JulAugSepOct  48
  NovDecJanFeb  49=46

Semesters
=========

6 months; 26 weeks, sometimes 27 weeks.

 - default set: 6x (offset ±0)
 - additional sets: 6x, 5x (or 7x)

 Offset: –2
 ----------
  NovDecJanFebMarApr     54
  MayJunJulAugSepOct   55=53

 Offset: –1
 ----------
  DecJanFebMarAprMay     57
  JunJulAugSepOctNov 58=56

  Solstice–Solstice 1 70?
  Solstice–Solstice 2 71?

 Offset: ±0
 ----------
  JanFebMarAprMayJun     61
  JulAugSepOctNovDec   62

 Offset: +1
 ----------
  FebMarAprMayJunJul     64
  AugSepOctNovDecJan 65=63

 Offset: +2
 ----------
  MarAprMayJunJulAug     67
  SepOctNovDecJanFeb     68=66

  North–Southward Equinox 60?
  South–Northward Equinox 69?

 Offset: ±3
 ----------
  AprMayJunJulAugSep     51
  OctNovDecJanFebMar     52=50

Offsets +2/–4 and ±3 are quite common in education and academics.
Reply | Threaded
Open this post in threaded view
|

Re: EDTF in ISO 8601-2

Christoph Päper-2
In reply to this post by Christoph Päper-2
Christoph Päper <[hidden email]> 2016-12-05:
>
> EDTF proposes -21, -22, -23 and -24 to use for the seasons (Northern/local) spring through winter, which are not defined in more detail. That may fit well with its focus on fuzzy dates (low precision or accuracy), but is unsatisfactory otherwise. I don’t like much the idea to overload CCYY-MM syntax with CCYY-SS, but it’s also been suggested to add notation for 2-, 4- and 6-month intervals, possibly with different start dates.

I’ve developed two alternative (but similar) numbering schemes in the meantime. They differ a) for some terms starting in the previous year or with October, November or December of the same year, and b) for trimesters. The first scheme uses the “first digit = number of month” convention as much as possible, the second one has more consistent numeral ordering (unless terms of different lengths are to be collated together). These schemes don’t care which terms would be likely to be used together.

- 20      DecJan: bimester starting with preceding December  
- 21      JanFeb: bimester starting with January  
- 22      FebMar: bimester starting with February
- 23      MarApr: bimester starting with March  
- 24      AprMay: bimester starting with April  
- 25      MayJun: bimester starting with May
- 26      JunJul: bimester starting with June  
- 27      JulAug: bimester starting with July  
- 28      AugSep: bimester starting with August
- 29      SepOct: bimester starting with September  
- 80 | 30 OctNov: bimester starting with October †  
- 81 | 31 NovDec: bimester starting with November †
- 82 | 32 DecJan: bimester starting with December †  

- 19 | 79 NovDecJan: trimester starting with preceding November *
- 30 | 80 DecJanFeb: trimester starting with preceding December
          = meteorological Central-European winter
- 31 | 81 JanFebMar: trimester starting with January – Q1
- 32 | 82 FebMarApr: trimester starting with February
- 33 | 83 MarAprMay: trimester starting with March
          = meteorological Central-European spring
- 34 | 84 AprMayJun: trimester starting with April – Q2
- 35 | 85 MayJunJul: trimester starting with May
- 36 | 86 JunJulAug: trimester starting with June
          = meteorological Central-European summer
- 37 | 87 JulAugSep: trimester starting with July – Q3
- 38 | 88 AugSepOct: trimester starting with August
- 39 | 89 SepOctNov: trimester starting with September
          = meteorological Central-European autumn
- 90      OctNovDec: trimester starting with October † – Q4
- 91      NovDecJan: trimester starting with November †
- 92      DecJanFeb: trimester starting with December †
          = meteorological Central-European winter

- 88 | 38 Oct..Jan: quadmester starting with preceding October *
- 89 | 39 Nov..Feb: quadmester starting with preceding November *
- 40      Dec..Mar: quadmester starting with preceding December
- 41      Jan..Apr: quadmester starting with January
- 42      Feb..May: quadmester starting with February
- 43      Mar..Jun: quadmester starting with March
- 44      Apr..Jul: quadmester starting with April
- 45      May..Aug: quadmester starting with May
- 46      Jun..Sep: quadmester starting with June
- 47      Jul..Oct: quadmester starting with July
- 48      Aug..Nov: quadmester starting with August
- 49      Sep..Dec: quadmester starting with September
- 50      Oct..Jan: quadmester starting with October
- 51      Nov..Feb: quadmester starting with November
- 52      Dec..Mar: quadmester starting with December

- 56      Aug..Jan: semester starting with preceding August
- 57      Sep..Feb: semester starting with preceding September
- 58      Oct..Mar: semester starting with preceding October
- 59      Nov..Apr: semester starting with preceding November
- 60      Dec..May: semester starting with preceding December
- 61      Jan..Jun: semester starting with January
- 62      Feb..Jul: semester starting with February
- 63      Mar..Aug: semester starting with March
- 64      Apr..Sep: semester starting with April
- 65      May..Oct: semester starting with May
- 66      Jun..Nov: semester starting with June
- 67      Jul..Dec: semester starting with July
- 68      Aug..Jan: semester starting with August
- 69      Sep..Feb: semester starting with September
- 70      Oct..Mar: semester starting with October
- 71      Nov..Apr: semester starting with November
- 72      Dec..May: semester starting with December
Reply | Threaded
Open this post in threaded view
|

Re: EDTF in ISO 8601-2

Christoph Päper-2
In reply to this post by Christoph Päper-2
Dear calendarists

If you were charge of adding a syntax for millenia C, centuries CC and decades CCY to ISO 8601, how would it look like?

I’m using the millenium 1000–1999, the century 1900–1999 and the decade 1960–1969 as examples. I know that sometimes 1001–2000, 1901–2000 and 1961–1970 would be preferred.

- C, CC, CCY: 1, 19, 196

- C___, CC__, CCY_: 1___, 19__, 196_
- C###, CC##, CCY#: 1###, 19##, 196#
- C***, CC**, CCY*: 1***, 19**, 196*
- C???, CC??, CCY?: 1???, 19??, 196?

- C‘XXX’, CC‘XX’, CCY‘X’: 1XXX, 19XX, 196X
- C‘VWX’, CC‘WX’, CCY‘X’: 1VWX, 19WX, 196X
- C‘XYZ’, CC‘XY’, CCY‘X’: 1XYZ, 19XY, 196X
- C‘XYZ’, CC‘YZ’, CCY‘Z’: 1XYZ, 19YZ, 196Z

- ‘K’C, ‘H’CC, ‘D’CCY: K1, H19, D196 – from SI prefixes kilo, hecto, deca/deka/(deci)
- C‘K’, CC‘H’, CCY‘D’: 1K, 19H, 196D – ditto
- ‘M’C, ‘C’CC, ‘D’CCY: M1, C19, D196 – from Romance-English ‘millenium’, ‘century’, ‘decade’
- C‘M’, CC‘C’, CCY‘D’: 1M, 19C, 196D – ditto

ISO 8601:2004 supports naked 2-digit centuries (CC), ISO/DIS 8601-2 adds 3-digit decades (CCY).

If you saw a string consisting of just 2 digits, say ‘10’, and knew it was supposed to be a valid ISO date or time, would you intuitively expect it to be CC, YY, MM, DD, WW, hh, mm or ss?