Re: CALNDR-L Digest - 29 Jul 2016 to 10 Aug 2016 (#2016-175)
Locked
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:
|
Re: CALNDR-L Digest - 29 Jul 2016 to 10 Aug 2016 (#2016-175)
|
|
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. |
Futile - First things First Re: CALNDR-L Digest - 29 Jul 2016 to 10 Aug 2016 (#2016-175)
|
|
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
|
Re: CALNDR-L Digest - 29 Jul 2016 to 10 Aug 2016 (#2016-175)
|
|
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 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:
|
EDTF in ISO 8601-2 was: CALNDR-L Digest - 29 Jul 2016 to 10 Aug 2016 (#2016-175)
|
|
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. |
Re: EDTF in ISO 8601-2 was: CALNDR-L Digest - 29 Jul 2016 to 10 Aug 2016 (#2016-175)
|
|
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. |
|
|
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 |
|
|
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? |
«
Return to Calndr-L
|
1 view|%1 views
| Free forum by Nabble | Edit this page |