→Gregorian calendar and ISO 8601: comment |
Mitch Ames (talk | contribs) →Readability and context.: reply |
||
Line 370: | Line 370: | ||
Because of the use of "''may'' be imposed" (this concept is echoed so many times with the "by mutual agreement" type of phrase in some documents) it means that there might or there might not be an obligation depending on the situation. In the TV example, if 2-2 wasn't severable but my contract/the law/etc made no requirements for it I could still chose to ignore it and technically be compliant because my agreement/scope of my application overrode the standard (or made irrelevant). Its discussed in various ways but basically they don't want the standard to become so rigid as to hold back an improvement in tech/science/etc. Their approach shows a preference for a general, more flexible, yet reasonably consistent standard which can be re-written in part or whole as the world changes. Anyway, all of this is just a very short (hahaha) summary of the 2nd half of 1 the ISO/IEC directives that didn't even touch on certain parts of it. |
Because of the use of "''may'' be imposed" (this concept is echoed so many times with the "by mutual agreement" type of phrase in some documents) it means that there might or there might not be an obligation depending on the situation. In the TV example, if 2-2 wasn't severable but my contract/the law/etc made no requirements for it I could still chose to ignore it and technically be compliant because my agreement/scope of my application overrode the standard (or made irrelevant). Its discussed in various ways but basically they don't want the standard to become so rigid as to hold back an improvement in tech/science/etc. Their approach shows a preference for a general, more flexible, yet reasonably consistent standard which can be re-written in part or whole as the world changes. Anyway, all of this is just a very short (hahaha) summary of the 2nd half of 1 the ISO/IEC directives that didn't even touch on certain parts of it. |
||
Crazy eh? So the point of all this (that is if you're still awake/sane ;) is that these standards, if they're ever going to get any sort of quality, are going to need to do so via reasonable, carefully considered, analysis & reasonable synthesis of the primary source(s). |
Crazy eh? So the point of all this (that is if you're still awake/sane ;) is that these standards, if they're ever going to get any sort of quality, are going to need to do so via reasonable, carefully considered, analysis & reasonable synthesis of the primary source(s). |
||
{{interrupted|JMJimmy|17:25, 15 August 2014 (UTC)}} |
|||
:{{gi|... via reasonable, carefully considered, analysis & reasonable synthesis of the primary source(s).}} |
|||
:Analysis and synthesis of primary sources is not the role of Wikipedia. [[WP:PRIMARY]] makes that clear thus: |
|||
:{{quotation| Do not analyze, synthesize, interpret, or evaluate material found in a primary source yourself ....}} |
|||
:Frankly, that is what you are doing, JMJimmy, and you ought not. |
|||
:Again from [[WP:PRIMARY]]: |
|||
:{{quotation| Do not base an entire article on primary sources, and be cautious about basing large passages on them ...}} |
|||
:This is what we ''all'' appear to be doing (myself included) and we probably ought not be. We should limit ourselves to "straightforward, descriptive statements of facts that can be verified by any educated person with access to the primary source but without further, specialized knowledge" You've described above how difficult it is to interpret the standards - it's clearly a specialist job, which means we ought not be doing it. This means that a lot of the detail probably ought to be removed. I don't believe we should be trying to include every detail of a technical standard into the article - we're not doing our readers any favours by trying. The nature of technical documentation is that any attempt to "reword" it (either to clarify it, or to avoid copyright issues) is likely to ''change the meaning'' of it. Perhaps we need to accept that we are trying to do too much - what we should be doing is giving an overview of the basic principles and ''not'' trying to get every little obscure detail correct. [[User:Mitch Ames|Mitch Ames]] ([[User talk:Mitch Ames|talk]]) 13:48, 16 August 2014 (UTC) |
|||
They'll require a higher level of discourse than is typical and even then they'll need heavy revisions to unpack the language and important aspects of the documents in a reasonable, encyclopedic fashion. In the same way that I will never understand what [[Quantum_harmonic_oscillator]] or [[Butyl]] articles are talking about, some may not understand these standards. I would not expect those articles to be dumbed down and made inaccurate/misleading/false simply so I could get a basic (&flawed) grasp of the topics. That said, I do think it is possible, to a certain degree, to unpack the language into a more readable format. That will likely take years to accomplish with the current state of the ISO series. It needs to start with information that is as accurate as possible, creates as little synth as possible, and then unpacking can follow. If it starts with unpacking there will be no baseline for accuracy and synth and falsehoods will find their way in with ease. The most recent addition to the page highlights this perfectly: |
|||
{{quotation|In general, ISO 8601 is limited to dates in the Gregorian (and potentially proleptic Gregorian) calendar, times based on the 24-hour timekeeping system, and combinations and intervals thereof.[1] It only applies when the dates and times are to be represented by numerical characters[1] (e.g. month numbers 1 to 12 rather than names January to December) and possibly separator characters (such as the colon in the time denoted "12:35").[2]}} |
{{quotation|In general, ISO 8601 is limited to dates in the Gregorian (and potentially proleptic Gregorian) calendar, times based on the 24-hour timekeeping system, and combinations and intervals thereof.[1] It only applies when the dates and times are to be represented by numerical characters[1] (e.g. month numbers 1 to 12 rather than names January to December) and possibly separator characters (such as the colon in the time denoted "12:35").[2]}} |
||
Knowing that notes in definitions provide normative supplements the "Gregorian calendar" definition includes: "NOTE In this International Standard the term Gregorian calendar is used to refer to the ''time scale'' described in 3.2.1". So right away we have inaccuracies & synth because the Gregorian/proleptic Gregorian calendars in general use are not the ones being described in the 3.2.1 time scale (close as they are). |
|||
⚫ | |||
{{interrupted|JMJimmy|17:25, 15 August 2014 (UTC)}} |
|||
:That paragraph is in the lead section; it's intended to be a simple overview of the keys points (per [[WP:LEAD]]) of the scope/purpose of the standard and when it is appropriate to use it, not include every detail, hence the first two words ''In general''. You're evidently not happy about [https://en.wikipedia.org/w/index.php?title=ISO_8601&diff=621196381&oldid=621196106 my] use of "Gregorian calendar" in that paragraph. However the intent of that paragraph is the same as section 1 Scope of 8601, which says (with my emphasis here) |
|||
⚫ | Sorry for the essay - I really didn't intend for it to stretch out like that but I think it's important people understand I'm not trying to be [[WP:TE|tendentious]] or [[WP:DE|disruptive]]. I think the subject matter is interesting and a challenge to understand at times let alone distill into encyclopedic content (if that's even possible lol). At the same time it's one that has been widely misunderstood as a result of that challenge and never risen to the level of quality due such a globally important series of topics. [[User:JMJimmy|JMJimmy]] ([[User talk:JMJimmy|talk]]) 17:25, 15 August 2014 (UTC) |
||
:{{quotation|This International Standard is applicable whenever representation of dates in the ''Gregorian calendar'', ...}} |
|||
:If it's good enough for the standard itself to summarise with that term I think it's probably OK for Wikipedia to do the same. |
|||
:{{gi|The 2nd sentence is just as bad, the standard states it does not cover representations ... where words are used. The latter seems to indicate Jan/Dec are not covered}}<br /> As my paragraph says, 8601 applies when dates are to be represented by numbers, not words. Ie 2014-08-16 (numbers, not words) is a valid 8601 representation of the date, but 16 August 2014 (includes words) is not - as I said, months are represented as numbers 1-12, not words Jan-Dec. [[User:Mitch Ames|Mitch Ames]] ([[User talk:Mitch Ames|talk]]) 13:48, 16 August 2014 (UTC) |
|||
⚫ | The more informational clause 5 tells us "if applicable, if the interchange of date and time representations ''derived from'' the date and time format representation has been agreed."... how can one derive something from the format of itself? Because accuracy was sacrificed for readability a massive chunk of the scope was left out. Namely, the "or of the formats of these representations". Once included, deriving from a format of one of the 3 listed representations makes a lot more sense all of the sudden. An interchange of an ISO 8601 compliant date representation, derived from a Julian calendar date in the format of a Gregorian calendar representation, is not outside the scope if it "has been agreed". The simple omission of 7 words radically changes the applicability of the standard and the reading of the rest of the article. In fact, while I haven't got a hold of it to verify the language, my understanding is that [[ISO 19108]] actually provides a standard for making the calculations from Julian to the ISO 8601 time scale. The 2nd sentence is just as bad, the standard states it does not cover representations where characters are not used (ie: non-number characters can, and are used) or where words are used. The latter seems to indicate Jan/Dec are not covered - I initially made this mistake myself. 1 January 14 is a valid Gregorian format and can be derived just like a Julian calendar date. The ''interchange'' does not use words (though it does use non-numerical characters like R/P1Y2M15DT12H/1985-04-12T23:20:50) but the deriving of the date can use ''specific'' words, listed in the standard, which have been assigned meanings. Each language of the ISO specifies the exact words which correspond with the month/day of the week. ie: French's ISO 8601 lists Février = 02 the same way the English version lists February = 02. They don't assign meaning to words/phrases/characters like "Year of the Rooster" for the Chinese calendar so those cannot be derived... without agreement ;) (gotta love that mutual agreement portion). |
||
⚫ | Sorry for the essay - I really didn't intend for it to stretch out like that but I think it's important people understand I'm not trying to be [[WP:TE|tendentious]] or [[WP:DE|disruptive]]. I think the subject matter is interesting and a challenge to understand at times let alone distill into encyclopedic content (if that's even possible lol). At the same time it's one that has been widely misunderstood as a result of that challenge and never risen to the level of quality due such a globally important series of topics. [[User:JMJimmy|JMJimmy]] ([[User talk:JMJimmy|talk]]) 17:25, 15 August 2014 (UTC) |
||
==Gregorian calendar and ISO 8601== |
==Gregorian calendar and ISO 8601== |
Revision as of 13:48, 16 August 2014
![]() | Time B‑class Top‑importance | |||||||||
|
Wikipedia dates
Some people have proposed using ISO 8601 for Wikipedia dates. For more of this discussion, see Wikipedia talk:Manual of Style (dates and numbers).
- It appears that it's rapidly becoming a de facto standard (if not yet de jure) at least for dates in Wikipedia citations.
Y10K
- The Long Now foundation suggests that years should be written with five digits (ie 02003 for the year 2003) in order to avoid the Year 10,000 problem.
This is pointless: all it does is push the problem forward a few years to 100,000, and situation already exists for dates in the past (-10,000 and earlier.) May as well accept that the year number can have a varying number of digits -( 18:57 22 Jun 2003 (UTC)
- RFC2550: Y10K and beyond — RFC document published as an April Fools joke in 1999; still it contains many potentially useful ideas.
Without seeing that I assumed they were serious! Brianjd
RFC: Does ISO 8601 use the Gregorian calendar?
Does ISO 8601 use the Gregorian calendar? If so, does this edit by JMJimmy help readers understand that ISO 8601 uses the Gregorian calender, or hinder that understanding? If the Gregorian calendar is used, is the wording as of 7 August 2014 (UT), JMJimmy's wording, or some other wording best? Jc3s5h (talk) 23:17, 9 August 2014 (UTC)
- Procedural note: this question represents only one side in the article. It does not even mention JMJimmy's position. I would suggest to reword it or, even better, remove {{RFC}} tag and use some more lightweight process (WP:3O or WP:DRN instead. — Dmitrij D. Czarkoff (talk•track) 09:07, 10 August 2014 (UTC)
ISO 8601 & Gregorian calendar discussion
As the originator of the RFC, I believe that ISO 8601 does use the Gregorian calendar. I also believe the wording as of 7 August 2014 is better than JMJimmy's version. Omitting hyperlinks and footnotes, the change amounts to this:
The standard uses the Gregorian calendar, which serves as an international standard for civil use.ISO 8601 fixes a reference calendar date to the Gregorian calendar of 20 May 1875 as the date the Convention du Mètre (Metre Convention) was signed in Paris.
This change obscures the fundamental point that ISO 8601 uses the Gregorian calendar, and leaves only a description of the indirect way ISO established a reference date of the calendar without getting into the complexity of the uncertain date of the Incarnation (Christianity) and Dionysius Exiguus' estimate of that date. Jc3s5h (talk) 23:17, 9 August 2014 (UTC)
- Text below was moved from Jc3s5h's talk page.
- I reapplied the changes and I just wanted to explain to you why in more detail. I took a step back and went to find the source. I was able to find a 3rd edition copy and it states in the Scope section: "This International Standard is applicable whenever representation of dates in the Gregorian calendar, times in the 24-hour timekeeping system, time intervals and recurring time intervals or of the formats of these representations are included in information interchange." There are two things which do not support any connection with "civil use". 1) it's limited to information interchange. 2) When parsed it includes more than Gregorian - that's just part of it. ie:
- ...whenever representation of dates in the Gregorian calendar...
- ...whenever representation of times in the 24-hour timekeeping system...
- ...whenever representation of time intervals and recurring time intervals... etc
- This is why the document refers to "local time" and "agreements on information interchange" because it knows that civil calendars are not unified and even within those that are timekeeping is not unified (see BENI time reports). It provides for mechanism (4.2.5.2) which use UTC +/- to convert local time to a standardized time to be formatted with the "Western" Gregorian calendar. Julian or Lunar time can be expressed via this ISO, it simply must be converted to UTC and expressed as "Western" Gregorian. Involving any sort of implication that the ISO has an impact or is impacted by civil use of a particular calendar is not supported by the citation nor the standard. For these reason I strongly believe that discussion of the level of adoption and the details of a particular calendar should be left in their respective articles.
- Additional comments:
- I never indicated that the ISO does not use the Gregorian calendar. It does without question. Section 3.2.1 The Gregorian calendar details this. What it avoids is any connection with any particular civil time other than for the conversion of local civil time into a standard time (using western Gregorian) for the purposes of information interchange. JMJimmy (talk) 23:34, 9 August 2014 (UTC)
- I'm having a hard time following this. The Gregorian calendar does not concern itself with time of day. "Civil calendar" is a calendar used for general secular use in a particular place. "Civil time" is the time-of-day used for general secular use in a particular place. They are almost separate ideas, except that the civil time determines when the transition occurs from one civil calendar day to the next. ISO 8601 allows local time, which is agreed to among the communicating parties or is implied by context, but which is not specified by the standard other than consisting of 24 hours in a day, 60 minutes in an hour, and 59 to 61 seconds in a minute. Alternatively, UTC can be used, or a combination of UTC and a time zone offset. Jc3s5h (talk) 23:46, 9 August 2014 (UTC)
- Addressing your assertion that "This change obscures the fundamental point that ISO 8601 uses the Gregorian calendar". If you feel that text does not adequately address Section 3.2.1 then it can be adjusted. My issue isn't with the reference to the Gregorian calendar - it's with the connection between the ISO and civil use. In fact I would encourage further detail on the use of Gregorian within the standard as the article is currently not clear that it uses a specific form of Gregorian (for those who don't know, Gregorian has numerous forms which are not compatible with this ISO unless first converted to UTC) These details would be great to include, but the moment you bring in "civil use" it then becomes about the calendar itself and not the standard. JMJimmy (talk) 23:55, 9 August 2014 (UTC)
- Clarification, this is the part I have a problem with: "which serves as an international standard for civil use.". I just removed the whole line because I thought it was clear enough by the paragraph below that it used Gregorian. Further to your last comment all calendars concern themselves with time to the extent that it is required to determine the change in date. When you bring in "civil use" it gives the impression that a) there is an actual standard (there's not, just a de facto use) b) that Gregorian is universally the same world wide, which it is not. 7% of the countries worldwide use a different civil calendar or modified Gregorian, it does not prevent them from converting to UTC and expressing in the specific Gregorian format discussed in the standard for the purposes of information interchange. JMJimmy (talk) 00:21, 10 August 2014 (UTC)
- There is exactly one Gregorian calendar for civil use. Its features include a sequence of days named January 1 through December 31 in the familiar sequence, the use of the year naming convention called AD or CE, and a rule for calculating leap years. Some things that are not defined by the Gregorian calendar include how time of day is measured or described, what time of day marks the end of one day and the start of another, and what date marks the first day of the calendar year. If a local calendar deviates from the Gregorian calendar, it isn't the Gregorian calendar, even if it's close.
- There is also a lunar Gregorian calendar, which uses an arithmetic rule to estimate the phase of the moon, and is used in computing the date of Easter in several Christian denominations. This is the part of the Gregorian calendar that is not for civil use, it is for religious use.
- I now see one, and only one, distinction between the Gregorian calendar for civil use and the ISO version of the Gregorian calendar. ISO 8601 insists that the first day of the calendar year is January 1. This is not a requirement of the Gregorian calendar, although our Gregorian calendar article indicates most European countries adopted January 1 as the beginning of the calendar year before, or at the same time as, adopting the Gregorian calendar. If such a distinction needs to be mentioned at all, I think it belongs in a footnote. Jc3s5h (talk) 00:48, 10 August 2014 (UTC)
- The easiest way I can show you that there are multiple calendars is: Microsoft's calendar dll those are fairly minor differences, part of the need for the ISO in question, Thai solar calendar is a version of Gregorian as is the Japanese calendar that info can be found in the wiki article here: Gregorian_calendar#Present_situation JMJimmy (talk) 02:03, 10 August 2014 (UTC)
- The Microsoft stuff is just different spellings of the month names and minor punctuation changes. That doesn't constitute a different calendar. As for the rest, a modified Gregorian calendar isn't the Gregorian calendar. When "Gregorian calendar" is written in an English language article, I think everyone has knows it isn't the Thai solar calendar. Jc3s5h (talk) 02:51, 10 August 2014 (UTC)
- I looked back into the page's history to see when this change was made. From Jan 2006 to Oct 2010 the text read that it was a de facto standard for international trade. Your edit changed the meaning to fit the source instead of sourcing the meaning. That is not a bad thing per se, just in this instance your source didn't relate to ISO and resulted in synth. I don't know where you're getting your info but you've made some assertions which are not supported by fact. ISO does not insist the 1st of January as being the calendar year. A calendar year is defined in the ISO as "cyclic time interval in a calendar which is required for one revolution of the Earth around the Sun and approximated to an integral number of calendar days NOTE 1 A calendar year is often also referred to as year. NOTE 2 Unless otherwise specified the term designates in this International Standard a calendar year in the Gregorian calendar.". In the standard it also states that it "...does not cover dates and times where words are used in the representation and dates..." and specifies the extent of the definition of the Gregorian calendar (it doesn't have all elements of it). This is what allows Japanese/Thai Gregorian style to interact with the ISO. Japan by example, could express a date as "平成二十六年 2014-08-09" and the ISO would ignore the language portion and only use the Gregorian compatible. As a programmer I've learned you have to be careful because in rare instances a date will be expressed as Heisei 26-2014-08-90 or Jan 1 26(2014), which could be interpreted as 2014-26-01. The point is, there's no reason to be imprecise about it by bringing in issues of civil use. The standard is explicit as to what it does use so why not stay true to that? JMJimmy (talk) 03:35, 10 August 2014 (UTC)
- The Microsoft stuff is just different spellings of the month names and minor punctuation changes. That doesn't constitute a different calendar. As for the rest, a modified Gregorian calendar isn't the Gregorian calendar. When "Gregorian calendar" is written in an English language article, I think everyone has knows it isn't the Thai solar calendar. Jc3s5h (talk) 02:51, 10 August 2014 (UTC)
- The easiest way I can show you that there are multiple calendars is: Microsoft's calendar dll those are fairly minor differences, part of the need for the ISO in question, Thai solar calendar is a version of Gregorian as is the Japanese calendar that info can be found in the wiki article here: Gregorian_calendar#Present_situation JMJimmy (talk) 02:03, 10 August 2014 (UTC)
- I now see one, and only one, distinction between the Gregorian calendar for civil use and the ISO version of the Gregorian calendar. ISO 8601 insists that the first day of the calendar year is January 1. This is not a requirement of the Gregorian calendar, although our Gregorian calendar article indicates most European countries adopted January 1 as the beginning of the calendar year before, or at the same time as, adopting the Gregorian calendar. If such a distinction needs to be mentioned at all, I think it belongs in a footnote. Jc3s5h (talk) 00:48, 10 August 2014 (UTC)
I have made a change to the article to replace the incomprehensible sentence involving the signing of the treaty of the meter with a definition of the Gregorian calender taken right from the standard. Jc3s5h (talk) 04:02, 10 August 2014 (UTC)
- I rewrote the section. The definition you used included a note "In this International Standard the term Gregorian calendar is used to refer to the time scale described in 3.2.1. " establishing the distinct separation of the standard from the definition supplied for that part. I also restored much of the deleted information as it was important. I tried to re-word it in a clearer way as you were right, it was awkward and confusing. The portion regarding the date chosen for the reference point should probably be expanded further as it's a very important distinction. It established a reference point with no religious significance to any religion. Instead they chose one with a both a scientific significance and a standardization significance. This made it easier for non-Christian states/companies/people to adopt the standard. I remember reading the history somewhere but I'm not up to researching/properly citing it at the moment (too many projects on the go). Cheers. JMJimmy (talk) 06:47, 10 August 2014 (UTC)
oh... side note, info on Alternate Format is missing if you (or anyone) feels up to tackling that JMJimmy (talk) 06:52, 10 August 2014 (UTC)
"expresses the term Gregorian calendar ..."
I disagree with this wording (as at this version):
The standard expresses the term Gregorian calendar to mean a, possibly infinite, time scale of adjoining calendar years and having several additional properties.
I don't think "expresses" is the correct word. 8601 expresses specific dates (from the Gregorian calendar) and times, durations and intervals - eg search the standard for "express" for numerous examples of that usage of the word. But it does not "express the term Gregorian calendar to mean..." - that phrase just does not make any sense. 8601 simply uses the Gregorian calendar, or possibly "expresses dates from the Gregorian calendar". I propose that this would be better:
The standard uses the Gregorian calendar, which provides ...
or, possibly:
The standard expresses dates from the Gregorian calendar, which provides ...
The second half of the sentence (as it currently stands) is, to my mind, unnecessarily convoluted. The wording is clearly a re-arrangement of the standard's 3.2.1 (apparently to avoid copyright violation) - it would probably be better to simply quote the standard thus:
The standard uses the Gregorian calendar, which provides "a, potentially infinite, series of contiguous calendar years",[1] with several additional properties.
I think a direct attributed quote in this context is fair use, and doesn't violate WP:QUOTE. Because this is in the Dates section, "time scale" is not necessary here, so I've removed it to keep the quote short. However, if you think it really matters:
The standard uses the Gregorian calendar, which "provides a time scale consisting of a, potentially infinite, series of contiguous calendar years",[1] with several additional properties.
(I think the shorter version is sufficient.)
Mitch Ames (talk) 09:43, 10 August 2014 (UTC)
- Given what you said, I agree that "expresses" is the wrong term.
- "uses" is not appropriate as "Gregorian calendar" is not being used it's being defined for use.
- "expresses dates" or "expresses dates from" also changes the meaning to indicate that "Gregorian calendar" is representative of a formula to express dates or fails to attribute the defining characteristics to the Gregorian calendar term.
- "time scale" must be kept otherwise it's meaningless.
- My concern with direct quoting is that there is already a significant amount of it in the text which is both an issue of policy (also if it's "fair use" it should be on wikisource) and copyright. That's why I attempted, and think it's important, to reword/reorder where rewording was not possible to create unique text that does not lose the meaning of the original.
- The sentence, expanded or otherwise, is intended to include these elements: 1) The standard is defining a specific version of the term "Gregorian calendar" (not that it merely states*) 2) That the term "Gregorian calendar" is a time scale 3) The time scale could be infinite 4) The time scale is comprised of adjoining years (adjoining has much the same meaning as "series of contiguous") 5) The time scale has reference point 6) The years have 52-53 weeks 7) The years are continuous and sequential (this language is hard to avoid) 8) The years are comprised of 365 or 366 days 9) Each year contains 12 months 10) Each month individually has a number of days 11) Those days are detailed in the standard
- If expanded into something more verbose, the separation must not cause any attributes described in 1-10 to be lost, changed, or improperly attributed. It should also not cause any confusion between the term being defined and the traditional term. (*I avoided the use of "define" so that it would not be easily confused with the "definitions" section which defines the basic traditional meaning for the term) JMJimmy (talk) 12:03, 10 August 2014 (UTC)
- I found the word! Delineates - to portray in words; describe or outline with precision. I'm more excited about this than I should be as I'm a little delirious from insomnia. I made a full pass over it (not sure if that was the smartest thing to do in my state) that I think cleans up a number of the issues with it (not all I'm sure) JMJimmy (talk) 19:30, 10 August 2014 (UTC)
The ISO has no authority to define the Gregorian calendar. If they purport to, they're idiots and we should not say in Wikipedia that the standard defines the Gregorian calendar. What they could do is describe that/those version(s) of the Gregorian calendar that are representable with the notation they define in their standard. Jc3s5h (talk) 12:23, 10 August 2014 (UTC)
- They are defining it for the standard and the standard alone. It has no bearing no the civil use of the Gregorian calendar whatsoever. It's a common practice in standards. They take a term that has a common understanding of what something is, use elements that will allow popular adoption of the standard (often that are shared among similar concepts), this allows for the standardization. By defining the term or the elements of the term used in the standard they are preventing any external changes from affecting the internal workings of the standard. ie: if Gregorian is reformed, outside ISO's control, in order to fix some short coming and it was not separately defined in the 8601 standard they could have a huge mess to fix. That mess may require complete abandonment of the standard or conflicting interpretations which could lead to disasters. If it is separate then they can do a controlled update or transition (if desired) to incorporate the reforms. JMJimmy (talk) 12:44, 10 August 2014 (UTC)
I have many points of disagreement with the version that Mitch Ames objects to (as at this version):
- It's too long.
- "Calendar dates prior to 1875-05-20 are still compatible with the ISO back to 1582-10-15"? This is meaningless.
- "Dates prior to 1582-10-15 are accomplished by the use of the proleptic Gregorian calendar and should only be used by mutual agreement." This is an inaccurate description of the standard, caused by only looking at the page this is paraphrased from, and not the whole standard. Page 13 states that year "values in the range [0000] through [1582] shall only be used by mutual agreement of the partners in information interchange."
- "The propleptic reference point year is '0000', which has 366 days." The standard doesn't say that. It just says 0000 is a leap year. I have no idea what "proleptic reference point year" means.
- "While the standard does not expressly forbid the use of alternate calendars they should not be used for exchange purposes." The standard says over and over that it uses the Gregorian calendar. The standard also specifies those aspects that may be varied by mutual agreement, and the Gregorian calendar there is no mention of being allowed to change to a different calendar by mutual agreement. So the calendar does exclude non-Gregorain calendars, although it does not use the word "forbid".
- "Dates from alternate calendars, if first converted to Gregorian UTC for expression, can be formatted using the standard as exampled by the Jet Propulsion Laboratory." This whole statement is unnecessary; of course dates can be converted from other calendars to the Gregorian calendar (if enough information has been preserved about the other calendar). Obviously after the date is converted to Gregorian, it can be expressed in the ISO 8601 format. If an example of a website that expresses a Gregorian date in ISO 8601 format is needed, put it in "External links". Also, the phrase "Gregorian UTC" is not a customary English or technical phrase; it just rams together two words that address different concepts.
Jc3s5h (talk) 13:00, 10 August 2014 (UTC)
- Addressing points in relation to the order listed in above comment
- Length is very very short considering the full text it's summarizing is over 2 pages long.
- It is not meaningless, it's establishing that a) the reference point is not defining an epoch or era b) due to a the calculations remain the same, but only until 1582-10-15 which is also not an epoch or era but is the end of the time scale
- It is not inaccurate as it encompasses what you stated (0000 - 1582-10-15) but also considers section 3.5 which allows for dates before 0000. Regardless of range any date prior to 1582-10-15 must use the proleptic Gregorian calendar and be by agreement. This is established clearly in section 3.2.1
- proleptic - defined so in terms of the standard the time scale is from 1582-10-15 to possible infinity. Proleptic Gregorian calendar is therefore prior to 1582-10-15. Because it exists outside of the defined time scale it's a time scale in its own right. As a result it needs a fixed reference point otherwise you cannot calculate anything properly. You can't use the post 1582 reference point because dates where calculated differently. (they dropped 10 days when adopting Gregorian). Hence, the proleptic reference year is 0000 and all other dates in the time scale can be calculated from that reference point. As to the standard "just saying it's a leap year" - a leap year always has 366 days.
- — JMJimmy 15:31, 10 August 2014 (UTC) — continues after insertion below
- The proleptic Gregorian calendar's only reference point is 1582-10-15, with all dates calculated backwards from that. As per the bottom of page 8 of the standard: "... no dates shall be inserted or deleted when determining dates in the proleptic Gregorian calendar. ... The Gregorian calendar was introduced on 15 October 1582. ... the calendar day preceding that ... is referred to as 14 October 1582." The year 0000 is noted as being a leap year, not as a reference point for calculating proleptic Gregorian calendar dates. Mitch Ames (talk) 14:21, 12 August 2014 (UTC)
- Since the time scale prior to 1582 can not have any knowledge of a time scale outside of its start/end points (if defined) it needs its own reference point. 0000 is an epoch and while the ISO doesn't make mention of it, it is a reference point (1875-05-20 is also an epoch, just that the ISO was moving away from that term to "reference point"). I'll add a citation JMJimmy (talk) 16:09, 12 August 2014 (UTC)
- Section 3.2.1 of the standard contains the passage "For the determination of calendar years, the year number and the calendar day within the calendar year only the rules mentioned above are used. For the purposes of this International Standard the calendar based on these rules is referred to as the Gregorian calendar." This means that the reference point, or epoch, is the signing of the 'Convention du Mètre' in Paris; the standard assigns the date 20 May 1875 to this event. The tables of month lengths and the leap year rule stated in section 3.2.1 can then be used to find what year should be assigned to any day in the past or future. It could be read to also mean that within the standard, the term "Gregorian calendar" applies to both before and after 15 October 1582, but that is not entirely clear. It may be that 15 October 1582 serves as a demarcation between what the standard refers to as the "proleptic Gregorian calendar" and the "Gregorian calendar", but it really doesn't matter; dates are determined by starting at 15 October 1582 and applying the rules stated in 3.2.1 either forward or backward in time. Similarly, there is nothing special about 0; it is merely the year between 1 and -1. But some readers of the standard might not be sure whether 0 should be considered evenly divisible by 400, so the standard explicitly states it is a leap year.
- You state "Since the time scale prior to 1582 can not have any knowledge of a time scale outside of its start/end points (if defined) it needs its own reference point." But there is no particular reason the reference point can't lie outside the start/end points of a time scale. When Dionysius Exiguus defined the Anno Domini year numbering system in 525, he used as the epoch his estimate of the Incarnation of Jesus, which he believed to be near the year 1.
- The Dershowitz and Reingold citation you added to the article does not support the notion that 0 is inherently a reference point; in that book on page 10 they wrote "We have chosen midnight at the onset of Monday, January 1, 1 (Gregorian) as our fixed date 1, which we abbreviate as R.D. 1" and on page 48 they wrote their gregorian-epoch equals by definition R.D. 1. Clearly these definitions are arbitrary (but convenient) choices they made for use within their book, and these definitions have no significance outside the book. Jc3s5h (talk) 17:02, 12 August 2014 (UTC)
- Since the time scale prior to 1582 can not have any knowledge of a time scale outside of its start/end points (if defined) it needs its own reference point. 0000 is an epoch and while the ISO doesn't make mention of it, it is a reference point (1875-05-20 is also an epoch, just that the ISO was moving away from that term to "reference point"). I'll add a citation JMJimmy (talk) 16:09, 12 August 2014 (UTC)
- The proleptic Gregorian calendar's only reference point is 1582-10-15, with all dates calculated backwards from that. As per the bottom of page 8 of the standard: "... no dates shall be inserted or deleted when determining dates in the proleptic Gregorian calendar. ... The Gregorian calendar was introduced on 15 October 1582. ... the calendar day preceding that ... is referred to as 14 October 1582." The year 0000 is noted as being a leap year, not as a reference point for calculating proleptic Gregorian calendar dates. Mitch Ames (talk) 14:21, 12 August 2014 (UTC)
- Dionysius didn't have computers. The standard is about "information interchange" and as such must be compatible with digital systems (see time scale notes and common sense). A computer given a time scale object cannot be assumed to know anything about any other time scale object. It especially cannot be assumed to be able to access information from another time scale object. If it goes looking for a time outside the bounds of its own time scale it can simply error out. It needs its own internal reference point to ensure it functions properly. As to the reference, I don't think you understand what its staying at all. Page 12 explains what an epoch is. Their R.D. (Rata Die meaning "fixed point") can be set at the epoch of any calendar for the purposes of the calculations. It doesn't change the epoch. Day 1 of the first year of the calendar. R.D. value of 1 just means that that is day 1 of the count. To put it in terms of the general use Gregorian calendar, an R.D. 1 value can be placed on 1582-10-15, the 16th would be R.D. = 2, the 14th would be R.D. = -1. It's just a counter. The proleptic Gregorian epoch doesn't change just like the general use Gregorian calendar's epoch (1582-10-15) doesn't change. The standard also specifies that a "time scale - system of ordered marks which can be attributed to instants on the time axis, one instant being chosen as the origin". All of this works just fine except that they honestly screwed up when they made the standard. By making Monday day 1 and Sunday day 7 the epoch doesn't compute as elegantly as it could. Had they made Saturday day 1 and Friday day 7 then the 1st day of the calendar would also have been the 1st day of the 1st week. Nice and tidy. There's a way to calculate it but it probably would have been easier if they just also defined that 0000 was a Saturday. JMJimmy (talk) 18:49, 12 August 2014 (UTC)
- Perhaps the wording can be changed here to be clearer. The intent is to establish that Gregorian incompatible calendars can be converted to Gregorian UTC and then expressed using the standards in Gregorian. It is NOT meant to indicate that Julian can be used directly with the ISO. Many have taken it to mean that other calendars are not allowed to be converted at all. To visualize it some think only this is allowed: "Gregorian → ← Gregorian". "Julian → ← Gregorian" is NEVER allowed. This is allowed: "Julian → Conversion to Gregorian UTC → Gregorian → ← Gregorian → Conversion to UTC → Julian" but only by agreement because, if the conversion is not accurate, it can cause problems. The JPL calculator does the latter example.
- Mostly addressed in previous comment. The "obvious" to you is not obvious to others, when someone who doesn't find it obvious reads "Julian calendar is incompatible with ISO 8061" they can it take to mean it can never be used in any way. Most wouldn't but someone who doesn't understand properly can make that leap and start to spread it. (like how wikihoaxes propogate) Regarding the "Gregorian UTC", this is not a "jamming together" of two words. UTC does not require the Gregorian calendar for input. 20140810 as Julian UTC would be 50430-07-14 12:00:00 where a Gregorian UTC would be 2014-08-10 00:00:00. As to the "example of Gregorian date as ISO", that's not what the demo does, it's Julian/UT/UT7. JMJimmy (talk) 15:31, 10 August 2014 (UTC)
- "Dates prior to 1582-10-15 are accomplished by the use of the proleptic Gregorian calendar and should only be used by mutual agreement" does reflect one page of the standard, but it is misleading because all years in the range 0000 to and including 1582 require mutual agreement, as explained in the "Years" section of the article. We shouldn't lay traps for readers by making statements that, in a hyper-technical sense, are true, but require careful perusal of the entire article to find important exceptions.
- About the paragraph
As a result of the consecutive date requirements, usage of the Julian calendar and other incompatible calendars would be contrary to the standard. While the standard does not expressly forbid the use of alternate calendars they should not be used for exchange purposes. Dates from alternate calendars, if first converted to Gregorian UTC for expression, can be formatted using the standard as exampled by the Jet Propulsion Laboratory here.
- Apparently you are concerned some readers might think standard purports to banish all non-Gregorian calendars in all spheres of life. You seem to feel that to avoid that misperception, we need to explain that the restriction only means that it is wrong to simply rearrange "Isaac Newton was born 25 December 1642" to "Isaac Newton was born 1642-12-25" and assert that statement complies with ISO 8601. I thought it was obvious that the ISO was only proposing a notation for expressing Gregorian calendar dates, and that other notations for Gregorian calender dates, as well as other calendars, would continue in use in parallel with ISO 8601.
- Here's why, comments appear like this: "for the official standard that one must only use it for Gregorian calendar dates". Someone who does not know better could read that, think it means that excludes using other calendars, checks the wiki to see if it's true and be none the wiser. They wouldn't know that the person meant the post-calculated input and formatting. The person who stated that, was you. (I honestly did not seek out a comment from you, it just showed up when I googled "must be gregorian" "iso 8601") There are many examples of similar ambiguities just on wikipedia Wikipedia_talk:Manual_of_Style/Dates_and_numbers/Archive_144 Wikipedia_talk:Manual_of_Style_(dates_and_numbers)/Archive_D6#Non-Gregorian_calendars. I think it's prudent to make it clear, though I do agree that my wording is not ideal. JMJimmy (talk) 18:50, 10 August 2014 (UTC)
- The standard, in section 3.2.1, states "The use of this calendar for dates preceding the introduction of the Gregorian calendar (also called the proleptic Gregorian calendar) should only be by agreement of the partners in information interchange." So far as the standard is concerned, the proleptic Gregorian calender is just a subset of the Gregorian calendar. Since the standard only uses the Gregorian calendar, there is no discontinuity or change in calculation rules at 1582-10-15T00:00, nor is there any discontinuity or change in calculation rules at 0000-01-01T00:00. Jc3s5h (talk) 16:32, 10 August 2014 (UTC)
- I think we're both almost right on this one lol. You're right that it's sequential and the method of calculation change I stated (re: 10 days) is wrong, not quite sure where my head was at. That said, while it conforms to all the rules in 3.2.1, it is still a new "instance" of a Gregorian calendar and each instance must have a reference point within its time scale. JMJimmy (talk) 18:50, 10 August 2014 (UTC)
- Per my previous comment above, the proleptic Gregorian reference point is defined on p8 of the standard as 1582-10-15 (the date from which we count backwards), not 0000. Mitch Ames (talk) 14:28, 12 August 2014 (UTC)
- I think we're both almost right on this one lol. You're right that it's sequential and the method of calculation change I stated (re: 10 days) is wrong, not quite sure where my head was at. That said, while it conforms to all the rules in 3.2.1, it is still a new "instance" of a Gregorian calendar and each instance must have a reference point within its time scale. JMJimmy (talk) 18:50, 10 August 2014 (UTC)
Jet Propulsion Laboratory link is a bad example
I propose that the the JPL example (the subject of these edits [1][2][3]) should be deleted - or replaced with a better example - because:
- The JPL Time Conversion Tool does not mention ISO 8601 at all
- None of the seven lines denoting date/time in Equivalent Times (or 13 instances if "=" separates two instances) comply with 8601, because "A.D." is not ISO-8601 compliant.
Even taking only parts of each line (and allowing the space delimiter instead of 8601's "T") for each time zone there are six representations, eg:
- A.D. 2014-Aug-11 11:52:41.00 = A.D. 2014-Aug-11.4949190
- A.D. 2014-08-11 11:52:41.00 = A.D. 2014-08-11.4949190
- A.D. 2014--223 11:52:41.00 = A.D. 2014--223.4949190
of which only one date and three times (in bold above) comply with 8601.
If we must say that "you can convert from other calendars to Gregorian and then represent with ISO 8601" (and I agree with Jc3s5h that this is unnecessary), we should provide an example that is clearly and explicitly ISO 8601 compliant. Mitch Ames (talk) 12:47, 11 August 2014 (UTC)
- That's true it does use multiple conversions and styles so it could be confusing. JMJimmy (talk) 14:36, 11 August 2014 (UTC)
- The paragraph containing the JPL example fails to bring out the central purpose of the standard. The standard is all about information interchange. It only applies at the moment information is interchanged from one partner to another (whether those partners be nineteen different mega-corporation, or two bits of software I wrote myself). It does not address how to do a calendar conversion (from, for example, an Arabic calendar or Unix time) nor it does it address how to convert the format from, for example, "this eleventh day of August in the Year of the Lord two thousand fourteen" to "2014-08-14". All is addresses is what the format must be at the moment the information is interchanged. The whole paragraph, if it is to be kept, needs to be rewritten. Jc3s5h (talk) 15:36, 11 August 2014 (UTC)
Strong objection to "Gregorian UTC"
At this moment the phrase "Gregorian UTC" does not appear in the article. Nevertheless, I need to express not only my strong objection to the phrase, but also the thought process that would lead anyone to write such a phrase. The standard may be used, if desired, to only express the calendar date without conveying the time of day. In such a case, UTC is irrelevant to the statement of data in ISO 8601 format. (How the person stating the date figured out the date, and whether that process involved UTC, is outside the scope of the standard.)
Also, the standard may be used to express the time and date in local time, without any statement, within the ISO 8601 formatted text, of how that local time relates to UTC. For example, we could rewrite a sentence from the article First Battle of Bull Run:
On 1861-07-21T02:30, McDowell sent the divisions of Hunter and Heintzelman (about 12,000 men) from Centreville, marching southwest on the Warrenton Turnpike and then turning northwest toward Sudley Springs.
This is a perfectly valid representation, even though the time is the local mean time of Manassas, Virginia, at a time when neither UTC nor time zones existed.
It is wrong to make any statement that a time must be in UTC, or convertible to UTC, in order to use the ISO 8601 format. Jc3s5h (talk) 17:02, 11 August 2014 (UTC)
- It is used it is also used as UTC (Gregorian) it's not common to express UTC as non-Gregorian, however, it is can be done. The terms are used by the likes of: Harvard Ohio State, Jet Propulsion Labratory. Here's an explanation from the ESA Space Trajectory Analysis software docs:
There are several possible formats to express time and date. Having a feature in the AM allowing the conversion between some of them, will allow not only the comparison of data with other sources, but also the adjustment to a particular user’s need. For this reason it was decided to provide time in the following formats: Gregorian UTC, Gregorian LCL, Julian UTC, Julian LCL, Time from Epoch (seconds, minutes, hours, or days), Mission Elapsed Time, YYDDD, Modified Julian Date (MJD), and Julian Date (JD) [9]. Since the time in STA is saved in the MJD format, all the necessary conversions should consider it as the starting point.
- While it's not specifically mentioned in the ISO, it's obviously important to be precise in the fact that, just because you have a UTC date, it does not mean that UTC date is in Gregorian. The same logic applies for ISO 8601 formatted dates - it cannot be assumed they refer to a Gregorian date - the links to the archives above discuss that extensively and that is why Wikipedia didn't adopt ISO8601. Please do not delete content that is under discussion when consensus has not been reached. Consensus was reached on the example and that has been removed. I strongly believe that this text is important for clarity and accuracy. (for clarity, I am not opposed to any sort of rewrite just opposed to it being removed/losing any accuracy) JMJimmy (talk) 20:58, 11 August 2014 (UTC)
- I agree that it is important to be precise as to what a date and time represent. I strongly agree that it is possible to use UTC in connection with some calendar other than Gregorian; Julian dates, modified Julian dates, and Julian calendar dates are only a few examples of such possibilities. It is equally possible to use the Gregorian calendar with time scales other than UTC; possibilities include UT1, a local time that is precisely convertible to UTC, and a local time that is not convertible to UTC because the event occurred before the invention of UTC. A Gregorian date based on any local time scale is representable in ISO 8601; the use of UTC is an option, not a requirement. Perhaps "Gregorian UTC" as shorthand after all the options had been discussed, but it should not be just introduced out of the blue.
- Although you don't say so in so many words, I think you would agree that seeing a date such as "1642-12-25" should not impel the reader who sees it to assume it obeys the ISO 8601 standard. I personally suspect that such confusion is a combination of causes. One cause is guys who have read brief summaries of ISO 8601 that only discuss how use it with modern dates, and the guys going off half-cocked thinking they know what to do with old dates. Another cause is guys who never heard of ISO-8601 who notice that the YYYY-MM-DD format is easy to sort with a computer, so spontaneously use that format without reading any standard. The problem is that your suspicions or mine about how people misuse language can't be added to Wikipedia because it is original research. To discuss this problem in the article, it would be necessary to find reliable sources which document that it is a genuine problem. If such documentation could be found, it would clearly be worthy of a separate section in the article. Jc3s5h (talk) 21:40, 11 August 2014 (UTC)
Disputed paragraph
The paragraph demanded by JMJimmy is false and I will point out the reasons sentence by sentence. First, the whole paragraph:
As a result of the consecutive date requirements, usage of the Julian calendar and other incompatible calendars would be contrary to the standard. While the standard does not expressly forbid conversion of incompatible calendars, such conversions must not be used for exchange purposes unless agreed to. If it is agreed to, the incompatible calendar should first converted to Gregorian UTC and formatted using the standard.
First sentence: "As a result of the consecutive date requirements, usage of the Julian calendar and other incompatible calendars would be contrary to the standard." For one thing, the consecutive date requirement is not the reason the Julian calendar or other incompatible calendars are contrary to the standard; they are contrary to the standard because the standard says to use only the Gregorian calendar (with the proleptic Gregorian calendar treated as a subset of the Gregorian calendar). Furthermore, if someone decided to ignore the Gregorian requirement and use the Julian calendar for both ancient and modern dates, there would be no violation of the consecutive date requirement.
Second sentence: "While the standard does not expressly forbid conversion of incompatible calendars, such conversions must not be used for exchange purposes unless agreed to." All the standard requires is that dates purported to obey the standard must be in the Gregorian calendar (as restricted within the standard) and written in the format specified in the standard. The standard does not require one information exchange partner to ask another information partner for permission to convert, for example, a Unix time to a Gregorian date before presenting it to the receiving information exchange partner.
Third sentence: "If it is agreed to, the incompatible calendar should first converted to Gregorian UTC and formatted using the standard." The phrase "If it is agreed to" is shown to be false in the discussion of the second sentence. "Converted to Gregorian UTC" is false because the standard does not require that days begin and end at midnight UTC, the standard does not require the use of UTC, and the standard does allow the use of local time without making any statement about how to convert that time to UTC time. Indeed, local time is allowed even if it is impossible to convert to UTC, such as events that occurred before UTC was established. Jc3s5h (talk) 21:03, 11 August 2014 (UTC)
- I re-read the standard in full to make sure I was not misunderstanding its scope or limitations - I do take what you have said in good faith and approach this with the mindset that I am in the wrong. After the re-reading I cannot agree with your statements. The standard does not say "to use only the Gregorian calendar", it says that it "is applicable whenever representation of dates in the Gregorian calendar ... are included in information interchange". Those two statements are VERY different. You are also ignoring the fact that is ONE of 4 applications for the standard (the part in the ... of the quote). The standard applies to (and I quote verbatim):
- representation of dates in the Gregorian calendar
- times in the 24-hour timekeeping system
- time intervals and recurring time intervals
- of the formats of these representations
- Note that last one. A Julian or ANY type of calendar or time system, that is in one of those 3 listed formats, are within the scope of the standard. *Note the exception to this is "where words" or "where characters are not used in the representation". Lets be clear, formats means the way in which something is arranged or set out. That means not that it must BE Gregorian, just that it must be formatted in the same way as Gregorian. The dates in Julian/other calendars/time systems, if FORMATTED in the same manner as Gregorian, are perfectly acceptable under the standard. Here's where I think it's confusing you, 3.2.1 defines a separate "Gregorian calendar". If you were to replace "Gregorian calendar/calendar" with anything, lets say "Force", and inserted the definitions for every instance that does not specifically refer to this Gregorian calendar then I think you'd have a very different interpretation. Here's an example of 3.2.1
This International Standard uses the [Force] for the identification of [a time interval[, known as a [force] day,] starting at midnight and ending at the next midnight, the latter being also the starting instant of the next [force] day. The duration of a [force] day is 24 hours]. This [force] provides a [system of ordered marks which can be attributed to instants on the [mathematical representation of the succession in time of instantaneous events along a unique axis], one instant being chosen as the origin] consisting of a, potentially infinite, series of contiguous [cyclic time interval in a calendar which is required for one revolution of the Earth around the Sun and approximated to an integral number of [force] days]. Consecutive [cyclic time interval in a calendar which is required for one revolution of the Earth around the Sun and approximated to an integral number of [force] days] are identified by sequentially assigned year numbers.
- Please note the 2 instances of "calendar" I did not change as they refer to any calendar not the one being defined or any specific calendar
- Reading it the above way I hope you can see that it's not stating that a particular calendar must be used at all. It's stating that whatever calendar is used must be calculated to a trip around the Sun and must be consecutive, (and follow the other rules). Someone might think that means "Julian doesn't follow those rules so it can't be used!", however, that would confuse the rules of the standard with the scope of the standard. Julian is within the scope of the standard, but in order to follow the rules of the standard it must be adapted to the rules of the [Force]. The reason I say it should be converted to Gregorian UTC has several reasons, 1) the standard "strongly recommends" the use of UTC, 2) UTC is corrected to UT1 so its more accurate, 3)Gregorian calendar dates should probably be re-calculated to Gregorian UTC as well as they don't always correspond exactly to UTC, and so on. I specified "Gregorian" UTC for accuracy since, as shown above, there is also a Julian UTC. Julian UTC does not conform to the rules of the [Force] even though it is proper UTC. I hope this makes sense to you, if not let me know. JMJimmy (talk) 23:36, 11 August 2014 (UTC)
- Well, that puts things in a different perspective. I didn't think it was possible for anyone to read the whole standard and not think the Gregorian calendar was mandatory for ISO 8601 dates. I can see that a close reading of "is applicable whenever representation of dates in the Gregorian calendar" could lead one to think it only means the standard is suitable for representing Gregorian dates, without eliminating other dates. But I think a fair reading of "This International Standard uses the Gregorian calendar for the identification of calendar days" (sec. 3.2.1) can only mean that the Gregorian calendar is the only allowable calendar.
- The example on the same page states
The Gregorian calendar was introduced on 15 October 1582. In the calendar set by this standard the calendar day preceding that calendar day is referred to as 14 October 1582. In the Julian calendar that calendar day is referred to as 4 October 1582.
- The example on the same page states
- Note the example says the day before Gregorian 15 October 1582 is 14 October 1582 in the calendar set by the standard.
- In the same section the standard takes the trouble to write out the Gregorian leap year rule but never mentions any other leap rule for any other calendar. Section 4.1.2.1 says "Calendar years are numbered in ascending order according to the Gregorian calendar by values in the range [0000] to [9999]...." [Emphasis added].
- RFC 3339 is a profile of ISO 8601 (that is, intended to be a compatible subset). The abstract of that document states
This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
- That document, which is likely to be more prominent than ISO 8601 itself, since it is freely available while ISO 8601 is expensive, unequivocally interprets ISO 8601 to require the Gregorian calendar. RFC 3339 has been around since 2002; there is an errata report which mentions only a few minor matters completely unrelated to which standard to use.
- The Web Exhibits Project, which is recommended on page 622 of the Explanatory Supplement to the Nautical Almanac (3rd ed, 2013), states
Can I write dates in the Julian calendar using ISO 8601? No. The Standard requires that the Gregorian calendar be used for all dates. Dates before the introduction of the Gregorian calendar are written using the proleptic Gregorian calendar. This is one of the few places where the proleptic Gregorian calendar is used. Thus the Julian date 12 March 826 must be written as 0826-03-16, because its equivalent date in the Gregorian calendar is 16 March.
- Finally, I don't think the authors were interested in creating a standard that would withstand critical analysis of the type that a lawyer who was trying to get his client out of a $100,000,000 debt would apply. Consider, for example, that UTC is only defined as differing from UT1 by an integral number of seconds, while in reality, there was a period of about 10 years when it differed from UT2 by a non-integral number of seconds. Or, it defines "standard time" as "time scale derived from coordinated universal time, UTC, by a time shift established in a given location by the competent authority" when in reality, standard time existed for nearly a century before UTC was invented. One must go with the general sense of the document. Jc3s5h (talk) 00:46, 12 August 2014 (UTC) Add another source 2:02 UT.
- You are confusing scope and rules again, two very different things. I'll deal with your assertions one at a time:
- Assertion: "Note the example says the day before Gregorian 15 October 1582 is 14 October 1582 in the calendar set by the standard."
- You're exactly right, you made my point. I don't think that's what you meant so lets go through it: "In the calendar set by this standard" How can a calendar be both set by this standard and be the one set by general use? It can't. Using the substitution method:
The Gregorian calendar was introduced on 15 October 1582. In the [force] set by this standard the [force] day preceding that [force] day is referred to as 14 October 1582.
- Maybe that makes it a little clearer that it does NOT mean: "the calendar set in the standard is the general use Gregorian calendar". What it is saying is that "In the the calendar day set by this standard, the calendar day preceding the day the general use Gregorian calendar was introduced, is 1582-10-14". It's contrasting the standards definition against the Gregorian/Julian changeover.
- Assertion: Gregorian leap year rule presence negates other calendars
- Again, confusing rules with scope. All calendars used with the ISO must conform to the rules. The leap year rules are in 3.2.1 paragraph 2 as well. It just means that any calendar needs to adjust to conform to the rules of the STANDARD, not the general use Gregorian calendar. You might also note in that 3.2.2 sets out the rules for weeks - if you check this out you can see it provides 15 different ISO calendars, 14 of them depending on which general use Gregorian calendar is used locally. If it was the general use Gregorian calendar, which one?
- Assertion: "Section 4.1.2.1 says "Calendar years are numbered in ascending order according to the Gregorian calendar by values in the range [0000] to [9999]...." [Emphasis added]"
- There are two problems with this, first - Gregorian calendar here term is the one defined by 3.2.1, the ISO standard, not the general use one. Second - as you've stated general use Gregorian calendar does not have dates from 0000 to 1582-10-14. One must extrapolate those dates in the same way you would Julian for use with the ISO. That's why proleptic is its own time scale with its own reference point.
- Assertion: RFC3339 text means ISO 8601 'is the Gregorian calendar.
- Read it again, make note of the "for representation of. That just means what part of the scope of ISO8601. By example the RFC does not deal with "time intervals" which is within the scope of the standard. If you read further you'll also see:
There are many ways in which date and time values might appear in Internet protocols: this document focuses on just one common usage, viz. timestamps for Internet protocol events.
the complete grammar for ISO 8601 is deemed too complex for most Internet protocols
- Assertion: Website says you can't write Julian dates in ISO8601
- It's ambiguous in its terminology but consistent with what I am trying to get across. The answer should say "When it is adjusted to the rules of the ISO standard: Yes. The Julian date 12 March 826 must be written as 0826-03-16, because its equivalent date in the ISO 8601 standard is 16 March."
- Assertion: Pretty much an ad hominem
- I won't address the ad hominem part but I will address this: "standard time existed for nearly a century before UTC was invented" You're very right and as pointed out in RFC3339:
To represent such historical time stamps exactly, applications must convert them to a representable time zone.
- The same as I'm talking about when using Julian and the same thing that is done for ISO dates prior to 1583.
- You are confusing scope and rules again, two very different things. I'll deal with your assertions one at a time:
- Finally, I don't think the authors were interested in creating a standard that would withstand critical analysis of the type that a lawyer who was trying to get his client out of a $100,000,000 debt would apply. Consider, for example, that UTC is only defined as differing from UT1 by an integral number of seconds, while in reality, there was a period of about 10 years when it differed from UT2 by a non-integral number of seconds. Or, it defines "standard time" as "time scale derived from coordinated universal time, UTC, by a time shift established in a given location by the competent authority" when in reality, standard time existed for nearly a century before UTC was invented. One must go with the general sense of the document. Jc3s5h (talk) 00:46, 12 August 2014 (UTC) Add another source 2:02 UT.
- 1) ISO (signing) has a different reference point than Gregorian (Easter) 2) Why would 2.1.4 mention "A time scale may amongst others be chosen as" and list calendars/scales that are not the same as Gregorian? Why would it refer to "successive step calendars", like the Japanese calendar, or "...usual calendars" 3) Why would 2.1.5 "For many time scales ... the origin of the time scale..." Why would origin matter if it's only for Gregorian? 4) 2.1.6 How would their be discontinuities between Gregorian and Gregorian? 5) 2.1.12 - UTC in itself is NOT Gregorian calendar even dismissing Julian UTC they don't match up 100% of the time. 6) 2.1.16 A non-UTC time of day? 7) 2.2.11 Why do they specifically mention "in the Gregorian calendar" if it has to be Gregorian? 8) 2.2.12 A month has 28-31 days but can also be months that all 30 days? 9) 2.2.13 seems to support your assertion in that the note specifies a calendar year to be a Gregorian calendar year. Except that in 2.2.15 the note states that "Gregorian calendar" is defined in 3.2.1 not the one in general use. I read 2.2.13 to mean calendar year is what is defined in 3.2.1. 10) 3.2.2 already mentioned that weeks don't match up, also day of the week vs date can be different between the two. 11) Section 3.3 Note the "together with the associated description". What's to describe if it's all Gregorian? 12) 4.1.2 furthers point 11 with the "unless specified otherwise" (ie: specified in the description/agreement)
- We can run around in circles but the fact is that, while extremely close and inspired by, ISO 8601 calendar is not the Gregorian calendar. ISO includes leap seconds, Gregorian does not (Gregorian is out 26 seconds per year). ISO weeks are different (ISO year 2000 week 1 began on 2000-01-03 where Gregorian began on (ISO)1999-12-31). You can eliminate Gregorian entirely and calculate ISO with Julian 2451546.5=2000-1-3 (and appropriate leap year calculations). ISO is compatible with Japanese/Thai style calendars, Gregorian is not. Here's some statistical data showing the difference between the two: [4] [5]. Then there's still the matter of the 14 Gregorian calendars. JMJimmy (talk) 09:23, 12 August 2014 (UTC)
- Would you agree that if a representation of a date is to satisfy the standard, the year, month, and date in the representation must be stated in a specialized variety of the Gregorian calendar which is described within the standard (but dates designated with a week number are described in a different part of the article)? The variety is selected from the Gregorian calendars in general use around the world by applying one rule that could be viewed as an expansion, and several restrictions:
- The specialized Gregorian calendar includes the proleptic Gregorian calendar, so all dates in the past or in the future can be expressed, provided that the data exchange partners agree to express dates outside the year range 1583 to 9999 inclusive. This provision will be viewed as an expansion to those accustomed to thinking the term "Gregorian calendar" does not include dates before 1583-1015.
- The first day of the year of the specialized Gregorian calendar is always January 1.
- The day always begins at midnight, according to whichever time-of-day scale is included in the representation. If no time-of-day scale is given, it is the local time in the place stated in ordinary language or implied by the circumstances.
- The portions of the Gregorian calendar that estimates the phase of the moon are outside the scope of the standard.
- The year 1 and later are in the year numbering system commonly known as Anno Domini, although the authors of the standard avoided the use of this term by stating "the Gregorian calendar has a reference point that assigns 20 May 1875 to the calendar day that the 'Convention du Mètre' was signed in Paris."
- Years earlier than 1 are counted sequentially, using 0 and the negative sign as necessary, in the manner of Astronomical year numbering. The method of representing year numbers is described elsewhere in the article.
- Jc3s5h (talk) 15:16, 12 August 2014 (UTC)
- I don't know what you mean exactly by "specialized variety" so I'm not quite sure what you're asking. One thing, just for the sake of clarity, the ISO "GCal" (tired of typing it in full lol) does not "include" the PGCal, if it's part of the exchange it's a separate time scale. ie: Time Scale 1 = 0000(or earlier) to 1582 Time Scale 2 = 1583 to 9999. Those time scales do not interact or combine (they're not a "stepping" calendar). You can define a time scale of -99999 to 99999 with agreement that doesn't involve separate time scales. You can also have an 1583-9999 that does not include PGCal but uses a different reference point (ie: if the 14 Gcals didn't include pgcal and kept their Dominical letter that would be valid with agreement)... the mutual agreement exceptions can change so much in the standard it'd be impossible to iterate. JMJimmy (talk) 17:33, 12 August 2014 (UTC)
- By specialized variety, I mean that there are a number of varieties of GCal that are, or were, in use, such as varieties that start the year on a date other than January 1. Of these, the standard has narrowed it down to two varieties to be used within the standard; one expresses dates with a year, month, and day, while the other expresses dates as a year, week number, and day. Lets dismiss the calendar that uses weeks for now.
- I view the standard as doing three distinct things. 1. Describes a variety of the GCal (and PGCal if you want to look at it that way) that allows a triplet of numbers to be assigned to any date. 2. It describes how to format the triplet for information interchange (in the case of years outside the range 0 to 9999, mutual agreement is required to determine how many digits to include in the year). 3. It imposes restrictions on what dates may be expressed without forming an agreement with the partners, and what "shortcuts" may be taken by mutual agreement, such as omitting the T from combined date-time representations.
- The standard does not attempt to impose on a person writing a conforming date any requirement on what order these things are performed (or described). One could say there is one calendar, which is the union of the PGCal and the GCal, which is described in the standard. Although all past and future dates exist in this calendar, some of them must not be expressed until agreement is reached with information exchange partners. You, apparently, are taking it in the opposite order; you seem to regard each date range for which there is a separate statement in the standard that mutual agreement is required constitutes a different calendar. I think the multiple calendar approach is harder to explain and work with. As an example of ease of use, partners who has already agreed to use ISO 8601 could come up with a simple statement like "we agree the year shall be represented with five digits, a sign shall always be used, and the allowable year range is -99999 to +99999" rather than "we agree the year shall be represented with five digits and a sign shall always be used, and the allowable calendars are the years -99999 to -00001, the years +00000 to +01582, and the years +01583 to +99999." Jc3s5h (talk) 18:12, 12 August 2014 (UTC)
- I would say that they narrowed it to the 4 varieties defined in their scope with varying expressions of each based in the specifications of the document. Aside from the computing requirements of the separate time scales, the reason its important to be able to have multiple time scales, as complicated as it can get, is that businesses and academia alike need them. Just taking the basic 0000-1582 & 1583-9999 - an agreement between universities could stipulate that the first time scale only need accuracy to the month where the second time scale must have accuracy to the day or even hour/time zone. If they were in a single calendar/time scale there would have to be complicated code to differentiate between them and may not detect errors like an improper space character which could make a 2nd time scale date/time look like a 1st time scale date. When you have 2 discrete time sets you can put strict rules to ensure it conforms just to what is specified for the individual time scale. This allows easier error checking & heuristics. Then there's things like the accounting usecase. They'll run a distinct calculation that still needs to be formatted properly but corresponds to tax years, employee pay schedules, etc. Having that time scale run concurrently with a normal time scale wouldn't be possible otherwise. JMJimmy (talk) 19:21, 12 August 2014 (UTC)
I do not believe the standard dictates, or even suggests, any particular structure for any computer program or computer data structure. One goal of the standard is to specify a calendar to be used when a date is in conformance to the standard and the year, month, and day is to be stated. (Defer consideration of time of day for now; just consider a day to be an observed passage of the sun across the sky at some fixed location, with the day beginning at midnight.) In order to specify such a calendar, it is necessary to specify two things; how to count, and how to relate the sequence to the real world by specifying that some event occurred on some stated date. How to count is specified by the tables giving the order and length of the months, together with the leap year rule. The sequence was related to the real world by assigning 20 May 1875 to the calendar day that the "Convention du Mètre" was signed in Paris. That provides criteria sufficient to assign a date to any day, provided the science of chronology is capable of providing a count of days between the event to be dated and 20 May 1875.
Computer programmers may wish to provide different data structures for different date ranges in order to apply the same constraints on all the dates in the range. For example, a motor vehicle department might have one date range for dates when cars didn't need to have titles, and another that begins the first day titles were mandatory. But that is outside the scope of the standard.
It will be necessary for the management of the interchange project to examine the range of dates that could possibly be valid for the information to be represented, and insure any necessary mutual agreements are in place. The finished programs may have input barriers to prevent dates that do not comply with the mutual agreements (or the requirements in the standard, if there are no agreements). The finished programs may also have internal tests to issue error messages if any dates are outside the allowed range. But the dates given special mention in the standard may not be limits in any particular project. If a project decides to allow dates between 1000-01-01 and 9999-12-31, there is no need to perform any tests involving 1582-10-15.
When we consider the time of day, matters become much more complicated. The standard provides considerable flexibility in this area. The representation can be limited to the year, month, and day, the date is in local time at some unspecified location. Exactly what meaning to assign to the date is deliberately vague. It allows one to write "the last mortgage payment is due at 1000 Figueroa Street, Los Angeles, California, on 2044-09-01." Context and customary business practices supply the additional information that the payment is due during whatever normal business hours are in force at that office of that lender about thirty years from now. The standard has provisions to specify a UTC time, or a UTC time with an offset for a local time zone. But it also provides the option to specify a local time. If the Congress was discussing a change in the date for the end of daylight saving time, and one was scheduling a meeting several months in advance and one didn't know if DST would be in effect or not one might schedule the time for 2015-10-15T19:00, and everyone would show up when their wrist watches read 7 PM, no matter what Congress decided. Jc3s5h (talk) 21:12, 12 August 2014 (UTC)
- The only one I read it as dictating, like you said, was the 1582/1583 split of time scales. Beyond that it's just examples of possibilities within. Anyway, I reworded the paragraph in question to remove any synth I had created and provided refs. Is it acceptable? JMJimmy (talk) 21:30, 12 August 2014 (UTC)
- The article still (at this version) says "The propleptic reference point year is '0000' " and I still disagree with that statement, for reasons that I've already listed. (I also agree with Jc3s5h's reasoning.) Mitch Ames (talk) 13:56, 13 August 2014 (UTC)
Revised disputed paragraph
The paragraph in question now reads
The standard does not forbid conversion of incompatible calendars to conform with the specifications therein. Conversions must not be used for exchange purposes unless mutually agreed to. If mutual agreement exists for conversion, the standard strongly recommends the use of Gregorian UTC in general, though does not make any requirements. Once conformed to the rules of the standard it can then be formatted as specified by the standard and the agreement.
[Citations omitted]
I will comment sentence by sentence. The first sentence is "The standard does not forbid conversion of incompatible calendars to conform with the specifications therein." That's true, but I don't understand what confusion the statement is intended to prevent. How could the ISO possibly prevent people from converting dates from one calendar to another before they use the standard to format the date? It's sort of like pointing out that McDonald's restaurants in the US don't forbid you from changing your Canadian bank notes to US bank notes before you come in and buy a meal.
The second sentence says "Conversions must not be used for exchange purposes unless mutually agreed to." No, the sentiment of this sentence is contrary to the whole concept of an interchange standard. The purpose of the standard is to specify the format and (to some degree) meaning of the data at the time it is passed outside the scope of the standard. As far as the standard is concerned, the sending party is free to use any method to convert a date in any calendar to the format and meaning required by the standard. Likewise, the receiving party is free to convert the standard date to any calendar the recipient pleases, without asking the sender for permission to do so.
The third sentence says "If mutual agreement exists for conversion, the standard strongly recommends the use of Gregorian UTC in general, though does not make any requirements." No. The section of the source cited to support this, 2.1.12, says in relevant part "The 15th Conférence Géneral des Poids et Mesures (CGPM) (1975) judged in its Resolution 5 that this usage can be strongly recommended." It is the Resolution 5 mentioned that endorses UTC, not the standard. If you read Resolution 5 you will see it is endorsing the practices of broadcasting UTC on standard time signal radio stations like WWV, and the practice of deriving civil time from UTC. It is also a bad idea; people and businesses usually deal with times in local time. In most cases it is better to include both the UTC and the time zone offset. In some cases, local time with no statement about UTC is better, such as events that occurred before standard time was invented.
The last sentence says "Once conformed to the rules of the standard it can then be formatted as specified by the standard and the agreement." That's true enough; if the paragraph needs to be in the article at all, that sentence can stay. Jc3s5h (talk) 22:27, 12 August 2014 (UTC)
- Where you not there for the massive discussion we just had? The confusion it is clearing up is the exact confusion that caused the discussion. It must be agreed to because if one party is expressing one type of date and the other is expressing another type of date they may not sync properly. ie: the 14 Gregorian ISO calendars - they all are slightly different but all are compliant to the standard. The only one you don't need a specific agreement for is the 15th of the ISO calendars on that list (linked above). 3rd sentence the standard strongly recommends it by including that note, nothing gets put in a standard without a purpose, if they put it in its because they are agreeing/echoing the statement. JMJimmy (talk) 07:55, 13 August 2014 (UTC)
- I think I'm beginning to see what you mean by "conversions". The 14 ISO week calendars stem from the possibility that someone might choose to express the date as year, week, day (so Sat 1 Jan 2005, rather than being written 2005-01-01, could be written 2004-W53-6). Certainly it would be a good business practice for information exchange partners to decide upon which allowable ISO 8601 format best suits their needs. Information exchange partners should decide if they want right now to be represented 2014-08-13, 2014-W33-03T10:11Z, or 2014-W33-T10:11-04. There is a requirement in section 3.3 that mutual agreement is required to use ISO 8601 at all ("By mutual agreement the parties in information interchange may transfer the date and time format representations. Only the date and time format representations permitted by this International Standard shall be used.") But there are a great many variations that may be used without further mutual agreement, such as the examples I just mentioned.
- You seem to be saying "Conversions must not be used for exchange purposes unless mutually agreed to" means the parties must decide which of the allowable formats will be used before transferring information. But if you search for the word "mutual" in the standard, you will see there is no separate requirement for this sound business practice. As far as the standard is concerned, once the parties agree to use ISO 8601, any standard without a "mutual agreement" proviso is fair game.
- Until now, I didn't realize that what you meant by "conversions". I though you were talking about conversions from non-Gregorian calendars. So if you worked for the US Citizenship and Immigration Service and I was an expert on middle eastern languages and calendars, and you hired me to summarize birth certificates from that part of the world, and I was to write birth dates in ISO 8601 format, I thought you were claiming that ISO 8601 demanded that we must agree on a list of middle eastern calendars I could convert from before I could begin work.
- You may think picking from one of the allowable formats in advance is a good business practice, and so do I, but we shouldn't put our personal opinion in the article. We would have to find a reliable source that gives this advice before putting it in the article. Jc3s5h (talk) 10:28, 13 August 2014 (UTC)
standard strongly recommends the use of Gregorian UTC - not
This recent addition:
The standard does not forbid conversion of incompatible calendars to conform with the specifications therein. Conversions must not be used for exchange purposes unless mutually agreed to. If mutual agreement exists for conversion, the standard strongly recommends[1] the use of Gregorian UTC[2] in general, though does not make any requirements. ...
- ^ ISO 8601:2004(E). ISO. 2004-12-01. p. 3 Section 2.1.12.
- ^ The Analysis Module of ESA’s Space Trajectory Analysis software Ana Margarida Teixeira Pinto Raposo Instituto Superior Técnico, Portugal, December 2010
is nonsense. In particular
- The standard does not mention "conversion of incompatible calendars" at all, much less say that "conversions must not be used ... unless mutually agreed to".
- 8601 section 2.1.12 does not recommend UTC. What Note 1 actually says is "The 15th Conférence Géneral des Poids et Mesures (CGPM) (1975) judged ... that this usage can be strongly recommended." The CGPM did not recommend UTC; it judged that it can be recommended, which is not the same thing. In any case CGPM is not ISO 8601, so even if you read Note 1 as meaning that CGPM recommended UTC, that does not mean that ISO 8601 recommends it. (The note also refers to "UTC", not "Gregorian UTC".)
- The Analysis Module of ESA’s Space Trajectory Analysis software does not mention ISO 8601 at all. ESA might use Gregorian UTC, but that tells us nothing about ISO 8601.
So I've deleted the paragraph. Mitch Ames (talk) 13:20, 13 August 2014 (UTC)
OK, I hadn't read #Revised disputed paragraph (about the same paragraph) before I jumped in, and now I have. But I haven't changed my mind - I still think it was nonsense, and that the best thing to do was just delete it. Mitch Ames (talk) 13:46, 13 August 2014 (UTC)
- That was the entire point. It does not mention it which leads people to believe that it can't be done (like the massive discussion above). Conversions or ANYTHING that isn't exactly in line with the standard needs mutual agreement because it can introduce errors otherwise. This is just common sense analysis of the text and it's many many mentions of by "agreement". ISO8601 *does* recommend UTC. Think about how these documents come to be - do you think it's like wiki and someone just drops a paragraph in on a whim? No. They're debated, mulled over, revised, etc. before the final version goes out. Somewhere along the lines of creating the document they thought it important enough to add a note to make it clear that UTC was "strongly recommended" (not just recommended, but strongly). They would not have included that otherwise, they would have just let CGPM make its recommendations in its corner and they issued their standards in theirs. ESA was simply a source for the term Gregorian UTC since, per discussion, it was thought I was "jamming two words" together. I'll reiterate, please do not delete text that is already under discussion until consensus is reached, it's rude. JMJimmy (talk) 15:53, 13 August 2014 (UTC)
It does not mention it which leads people to believe that it can't be done ...
This appears to be pure speculation on your part.Conversions or ANYTHING that isn't exactly in line with the standard needs mutual agreement
Nonsense. Suppose we agree to exchange date/time information according to ISO 8601. I do not have to mutually agree with you on whether I convert the month from a number to a name (08 --> August) after I receive the data. As long as we both comply with the standard at the point of information interchange, that is sufficient. I don't know or care whether you store your months as numbers or words, or whether you store them in Julian date format or as Unix time and convert them before/after communicating them with me.This is just common sense analysis of the text ...
That is WP:ANALYSIS, a.k.a. original research, and misuse of a primary source, which we are not supposed to do.... and it's many many mentions of by "agreement"
None of those mentions are in relation to conversion from/to incompatible calendars.ISO8601 *does* recommend UTC.
No it does not. It notes that CGPM judged that UTC can be recommended. That's all. Anything else is analysis - "interpretation of primary source material". If ISO 8601 actually recommended UTC they'd say so explicitly, for example as they do in 3.2.3 (with my emphasis here): "This International Standard recommends the use of time scales applying the 24-hour time keeping system ..."ESA was simply a source for the term Gregorian UTC
ESA does not define the term Gregorian UTC so it's not a good reference for that purpose. ESA doesn't mention 8601, so it's not a good reference for the statement that "the standard strongly recommends the use of Gregorian UTC" (which is implied by the location of that ref without any other qualification, eg an explanatory note). At best, that ref would support a statement that "some entities use the term 'Gregorian UTC' ", but given that the ref doesn't mention 8601, and 8601 doesn't mention Gregorian UTC, such as statement would be completely meaningless in an article about 8601.- Mitch Ames (talk) 10:56, 14 August 2014 (UTC)
Clauses or sections
The article currently uses both "clause" and "section" to denote numbered clauses/sections of the standard, but ideally we would use only the one term. I was of the view that ISO used the term "clause" in its standards - eg ISO/IEC 7816 does - but searching through 8601 I find no use of the term "clause" and two usages of "section" (in 4.4.3 and 4.4.5, but referring to other numberer sections).
Should replace "clause" with "section" in our article, where referring to sections of 8601? Mitch Ames (talk) 08:54, 10 August 2014 (UTC)
- Clause refers to a group of sections. Section refers to a specific section within a clause. ie: "Clause 4" is everything from 4 to 4.5.4. While section 4.2.4 applies to that specific point. JMJimmy (talk) 09:07, 10 August 2014 (UTC)
words or non-character are not part of the standard
I've deleted this:
With the exception of day of the week, words or non-character are not part of the standard.[1]
from the Week dates section, because the days of the month are part of the standard. What the standard actually says is that it "does not cover dates and times where words are used in the representation and dates and times where characters are not used in the representation". If we want to include that information, it needs to be paraphrased more accurately, and in a section that covers more than just week dates. Mitch Ames (talk) 13:28, 12 August 2014 (UTC)
- What section do you think is appropriate? (also I forgot to include month names along with day of the week) JMJimmy (talk) 17:01, 12 August 2014 (UTC)
- A brief summary of the scope is appropriate in the lead section - thus. Mitch Ames (talk) 11:24, 14 August 2014 (UTC)
Readability and context.
The dates section of this article begins "The standard delineates Gregorian calendar to mean a, possibly infinite, time scale of adjoining calendar years that has a reference point as well as several properties and limits. The properties include continuous/sequential numbering of years..." This is not gramatically readable nor does it provide any context. I don't care too much about the factual accuracy of it or any other versions, but if this paragraph is going to stay for any significant amount of time it needs to add context and be phrased in a way that is readable by the average reader. CombatWombat42 (talk) 17:57, 13 August 2014 (UTC)
- Readability issue is agreed by all, including myself, and was under discussion above before it got side tracked. I'm not sure what you mean by context in this case, could you elaborate? JMJimmy (talk) 19:11, 13 August 2014 (UTC)
- Pulled out of the previous derailed conversation.
- The sentence, expanded or otherwise, is intended to include these elements: 1) The standard is defining a specific version of the term "Gregorian calendar" (not that it merely states*) 2) That the term "Gregorian calendar" is a time scale 3) The time scale could be infinite 4) The time scale is comprised of adjoining years (adjoining has much the same meaning as "series of contiguous") 5) The time scale has reference point (1875 signing) 6) The years have 52-53 weeks 7) The years are continuous and sequential (this language is hard to avoid) 8) The years are comprised of 365 or 366 days 9) Each year contains 12 months 10) Each month individually has a number of days 11) Those days are detailed in the standard
- If expanded into something more verbose, the separation must not cause any attributes described in 1-10 to be lost, changed, or improperly attributed. It should also not cause any confusion between the term being defined and the traditional term. (*I avoided the use of "define" so that it would not be easily confused with the "definitions" section which defines the basic traditional meaning for the term). How best to accomplish all of the above in a more readable way I'm not sure of. JMJimmy (talk) 19:22, 13 August 2014 (UTC)
- I have not previously edited this article but was asked to comment by Jc3s5h. I found the first few paragraphs readable and have inserted a request for clarification of one point I was unable to follow. When I got to the section beginning "The standard delineates Gregorian calendar ... " I found it impenetrable, and don't see the point of including it in its present form. I have read it 3 times and I still don't get it. Why not edit the text here on the Talk page first? Dondervogel 2 (talk) 11:35, 15 August 2014 (UTC)
Please excuse the lack of indenting and length.
The documentation state of the ISO standards on Wikipedia is woefully poor. List of International Organization for Standardization standards lists many of them and of the ones that aren't unlinked/red-linked a bunch are re-directs back to that page (like ISO 19108). These standards are incredibly important as their referenced by the highest levels of industry/science and trickle down through other standards like the internet RFCs. I do not claim to be an expert on them by any means, however, I am able to recognize a significant portion of what is written about them is simply not factually accurate. Being written at such a high level they are also incredibly dense grammatically (a sentiment echoed by the RFC which I quoted above) and can very easily be misinterpreted. Another part of the problem is that they're not open standards so unless the documents leak or are provided free they're not likely to end up in the hands of very many people (they're also very protective and DCMA a lot). The result is very little in the way of quality secondary sources. For each ISO I could dig up dozens different interpretations of any given standard from secondary sources. Especially secondary sources that are applying a given standard, though nothing that should ever be considered a quality source.
The reason they should never be considered quality sources is because many of those interpretations can be accurate to the scope and implementation of their application and agreements. If put on the same plane as another project with a similar, but slightly different scope/implementation/agreement the former would not meet the standard while the latter would. Confusingly, the reverse can also be true without changing anything. So how can both be "right" and "wrong" at the same time? A lot of it comes down to the contents of the ISO/IEC Directives. Part 2 is a 72 page standard on how to write and interpret the standards that includes 31 ISOs/documents in its normative references alone. There are also ISO/IEC "Guides" which provide "rules, orientation, and advice or recommendations", there are corrigendums which make corrections without publishing a revision of the standard, actual revisions of the standard, superseding of standards by others in part or whole, and ISO/TCs which must be taken into consideration.
Thrown for a loop yet? It gets more complicated. Where a document doesn't supersede another and where they both have a term defined, the one which defines the concept first is the definition to be used in the later but only so far as it can within its scope. If outside its scope the newer definition applies so long as it is still homogenous with the concept as a whole through all docents. Another aspect is that notes in the definitions section have a different set of rules and interpretation than notes within the text. Notes in the text can only give information for understanding the document, they can't make any sort of normative requirement (ie: they can never use: shall/shall not, should/should not, can/cannot, may/need not). They can state fact though. Notes in the definitions section can use those statements to provide normative requirements, supplemental definition, provisions for use, etc. Annexes, footnotes, tables, and figures (and combinations there of) are similarly complicated.
Ready for the curve ball? Even given all of that there are two elements which can completely twist your mind inside out trying to figure them out. First, the clauses and subclauses (sections) are somewhat severable. That's to mean that, based on the structure of the document the standard changes what is required, recommended, stated, or severable to a particular use for the standard. A simple example they give is:
- Part 1: General requirements
- Part 2-1: Requirements for plasma displays
- Part 2-2: Requirements for monitors
- Part 2-3: Requirements for LCDs
Clause 1 (part 1) applies to all subsequent clauses/subclauses. Clause 2 though is severable based on the application. If I am using the standard for a LCD TV I can sever subclauses 2-1 and 2-2 from the standard and still be compliant since they're not in the scope of my application. If I'm making an LCD monitor though, I cannot sever section 2-2 because it is within the scope of my application. Note I said "somewhat severable" before, lets say subclause 2-3 has 2 subclauses 2-3-1 and 2-3-2. If I am making an LCD TV and 2-3-1 makes a dated or undated reference to clause 2-2 that means that can't sever 2-2 if I want to be compliant. (dated/undated reference being "2-3-1 blah blah blah (see 2-2) blah blah"). And then comes the final twist:
A document does not in itself impose any obligation upon anyone to follow it. However, such an obligation may be imposed, for example, by legislation or by a contract. In order to be able to claim compliance with a document, the user needs to be able to identify the requirements he/she is obliged to satisfy. The user also needs to be able to distinguish these requirements from other provisions where there is a certain freedom of choice.
Because of the use of "may be imposed" (this concept is echoed so many times with the "by mutual agreement" type of phrase in some documents) it means that there might or there might not be an obligation depending on the situation. In the TV example, if 2-2 wasn't severable but my contract/the law/etc made no requirements for it I could still chose to ignore it and technically be compliant because my agreement/scope of my application overrode the standard (or made irrelevant). Its discussed in various ways but basically they don't want the standard to become so rigid as to hold back an improvement in tech/science/etc. Their approach shows a preference for a general, more flexible, yet reasonably consistent standard which can be re-written in part or whole as the world changes. Anyway, all of this is just a very short (hahaha) summary of the 2nd half of 1 the ISO/IEC directives that didn't even touch on certain parts of it.
Crazy eh? So the point of all this (that is if you're still awake/sane ;) is that these standards, if they're ever going to get any sort of quality, are going to need to do so via reasonable, carefully considered, analysis & reasonable synthesis of the primary source(s). — JMJimmy 17:25, 15 August 2014 (UTC) — continues after insertion below
... via reasonable, carefully considered, analysis & reasonable synthesis of the primary source(s).
- Analysis and synthesis of primary sources is not the role of Wikipedia. WP:PRIMARY makes that clear thus:
Do not analyze, synthesize, interpret, or evaluate material found in a primary source yourself ....
- Frankly, that is what you are doing, JMJimmy, and you ought not.
- Again from WP:PRIMARY:
Do not base an entire article on primary sources, and be cautious about basing large passages on them ...
- This is what we all appear to be doing (myself included) and we probably ought not be. We should limit ourselves to "straightforward, descriptive statements of facts that can be verified by any educated person with access to the primary source but without further, specialized knowledge" You've described above how difficult it is to interpret the standards - it's clearly a specialist job, which means we ought not be doing it. This means that a lot of the detail probably ought to be removed. I don't believe we should be trying to include every detail of a technical standard into the article - we're not doing our readers any favours by trying. The nature of technical documentation is that any attempt to "reword" it (either to clarify it, or to avoid copyright issues) is likely to change the meaning of it. Perhaps we need to accept that we are trying to do too much - what we should be doing is giving an overview of the basic principles and not trying to get every little obscure detail correct. Mitch Ames (talk) 13:48, 16 August 2014 (UTC)
They'll require a higher level of discourse than is typical and even then they'll need heavy revisions to unpack the language and important aspects of the documents in a reasonable, encyclopedic fashion. In the same way that I will never understand what Quantum_harmonic_oscillator or Butyl articles are talking about, some may not understand these standards. I would not expect those articles to be dumbed down and made inaccurate/misleading/false simply so I could get a basic (&flawed) grasp of the topics. That said, I do think it is possible, to a certain degree, to unpack the language into a more readable format. That will likely take years to accomplish with the current state of the ISO series. It needs to start with information that is as accurate as possible, creates as little synth as possible, and then unpacking can follow. If it starts with unpacking there will be no baseline for accuracy and synth and falsehoods will find their way in with ease. The most recent addition to the page highlights this perfectly:
In general, ISO 8601 is limited to dates in the Gregorian (and potentially proleptic Gregorian) calendar, times based on the 24-hour timekeeping system, and combinations and intervals thereof.[1] It only applies when the dates and times are to be represented by numerical characters[1] (e.g. month numbers 1 to 12 rather than names January to December) and possibly separator characters (such as the colon in the time denoted "12:35").[2]
Knowing that notes in definitions provide normative supplements the "Gregorian calendar" definition includes: "NOTE In this International Standard the term Gregorian calendar is used to refer to the time scale described in 3.2.1". So right away we have inaccuracies & synth because the Gregorian/proleptic Gregorian calendars in general use are not the ones being described in the 3.2.1 time scale (close as they are). — JMJimmy 17:25, 15 August 2014 (UTC) — continues after insertion below
- That paragraph is in the lead section; it's intended to be a simple overview of the keys points (per WP:LEAD) of the scope/purpose of the standard and when it is appropriate to use it, not include every detail, hence the first two words In general. You're evidently not happy about my use of "Gregorian calendar" in that paragraph. However the intent of that paragraph is the same as section 1 Scope of 8601, which says (with my emphasis here)
This International Standard is applicable whenever representation of dates in the Gregorian calendar, ...
- If it's good enough for the standard itself to summarise with that term I think it's probably OK for Wikipedia to do the same.
The 2nd sentence is just as bad, the standard states it does not cover representations ... where words are used. The latter seems to indicate Jan/Dec are not covered
As my paragraph says, 8601 applies when dates are to be represented by numbers, not words. Ie 2014-08-16 (numbers, not words) is a valid 8601 representation of the date, but 16 August 2014 (includes words) is not - as I said, months are represented as numbers 1-12, not words Jan-Dec. Mitch Ames (talk) 13:48, 16 August 2014 (UTC)
The more informational clause 5 tells us "if applicable, if the interchange of date and time representations derived from the date and time format representation has been agreed."... how can one derive something from the format of itself? Because accuracy was sacrificed for readability a massive chunk of the scope was left out. Namely, the "or of the formats of these representations". Once included, deriving from a format of one of the 3 listed representations makes a lot more sense all of the sudden. An interchange of an ISO 8601 compliant date representation, derived from a Julian calendar date in the format of a Gregorian calendar representation, is not outside the scope if it "has been agreed". The simple omission of 7 words radically changes the applicability of the standard and the reading of the rest of the article. In fact, while I haven't got a hold of it to verify the language, my understanding is that ISO 19108 actually provides a standard for making the calculations from Julian to the ISO 8601 time scale. The 2nd sentence is just as bad, the standard states it does not cover representations where characters are not used (ie: non-number characters can, and are used) or where words are used. The latter seems to indicate Jan/Dec are not covered - I initially made this mistake myself. 1 January 14 is a valid Gregorian format and can be derived just like a Julian calendar date. The interchange does not use words (though it does use non-numerical characters like R/P1Y2M15DT12H/1985-04-12T23:20:50) but the deriving of the date can use specific words, listed in the standard, which have been assigned meanings. Each language of the ISO specifies the exact words which correspond with the month/day of the week. ie: French's ISO 8601 lists Février = 02 the same way the English version lists February = 02. They don't assign meaning to words/phrases/characters like "Year of the Rooster" for the Chinese calendar so those cannot be derived... without agreement ;) (gotta love that mutual agreement portion).
Sorry for the essay - I really didn't intend for it to stretch out like that but I think it's important people understand I'm not trying to be tendentious or disruptive. I think the subject matter is interesting and a challenge to understand at times let alone distill into encyclopedic content (if that's even possible lol). At the same time it's one that has been widely misunderstood as a result of that challenge and never risen to the level of quality due such a globally important series of topics. JMJimmy (talk) 17:25, 15 August 2014 (UTC)
Gregorian calendar and ISO 8601
The authors of ISO 8601 felt the need to describe the Gregorian calender so it was unambiguously defined, (or in a sense, they were unambiguously defined) without relying on any of the documents related to the calendar that were written by the Roman Catholic Church. But that does not mean Wikipedia has to repeat that formulation. Although some historical variations and some variations used in limited geographies exist, there is one Gregorian calendar that is used for daily secular life in Europe and many countries who's development was strongly influenced by Europe (Australia, Canada, Mexico, and the United States, to name a few). So all we need to do is make it clear that the familiar international commerce version of the Gregorian calendar is the one used in the standard, together with the proleptic Gregorian calendar.
The standard also allows for the possibility of using a week representation, such as 2014-W33-5 for today. We have an article about it. A feature of this week-based system is that the year does not change in the middle of a week, so although derived from the Gregorian calendar, it isn't really the same calendar. Nachum Dershowitz and Edward Reingold in Calendrical Calculations have a short chapter, 5, devoted to this. They don't call it (or them) the Gregorian calendar; they call it "The ISO Calendar". So when I write "Gregorian calendar" I am excluding variations that prevent the year from starting mid-week.
Obviously the Gregorian calendar was introduced when there were no good clocks; today we have the possibility of deciding when days begin and end by referring to atomic clocks, and ignoring the passage of the Sun across the sky, but that was not possible in the 16th century. So the Gregorian calendar counts days, and until the introduction of standard time, it was implicitly the count of days in a particular location. There are an infinite number of ways to use the Gregorian calendar, depending on where the observer is counting days, but these are not considered different calendars, just different locations.
So if someone wants to convince me that the international commerce version of the Gregorian calendar is different from the calendar that ISO uses when representing dates in the form YYYY-MM-DD, let them prove a concrete example that results in a different date depending on which one you use. Jc3s5h (talk) 20:04, 15 August 2014 (UTC)
- Aside from the RFC3339 you quoted doing just that, http://www.math.harvard.edu/computing/javascript/Calendar/ Enter a date of 2000-01-01 (completion of an earth rotation is set at midnight so leave the time as 00:00:00). Hit calculate and scroll to ISO-8601 Week and Day, and Day of Year. ISO shows Day 6 of week 52 of year 1999 where Gregorian is Day 1 of year 2000. Joys of the 26 second problem. After 3,323 years Gregorian will be 1 day off. Who cares right? It'll be almost the year 5000 before it becomes an issue and we'll be long dead! Who cares! Problem is, if the world were on true Gregorian calendar right now, midnight would be at about 8:54pm. We're already over 3 hours off JMJimmy (talk) 20:55, 15 August 2014 (UTC)
- There are two problems with your post. The first problem is "scroll to ISO-8601 Week and Day, and Day of Year". I wrote above "So when I write "Gregorian calendar" I am excluding variations that prevent the year from starting mid-week." So the fact that 2000-01-01 could also be represented 1999-W52-06 is not what I am discussing; we have a different article about that, as well as a section within this article.
- The second post is "After 3,323 years Gregorian will be 1 day off." Off from what? Timekeeping (figuring out the time of day) has traditionally been a separate subject from calendars. It has always, right from the introduction of the Gregorian calender, to be perfectly normal to keep it with many different timekeeping authorities, and still call it "the Gregorian calendar". The original goal of the Gregorian calendar was to keep Easter throughout the world on the same day; the day that the creators of the calendar considered correct according to their religious beliefs. But each and every church (as in a church building) that adopted and observed the Gregorian calendar kept time differently because they were in different locations. So if one guy wants to hypothesize that days will be counted by physical passages of the Sun at a particular location, and another wants to hypothesize that the Gregorian calendar will be used together with International Atomic Time, and they have a meeting and observe that after 3000 or so years the two of them would be observing Easter on different days, so what? They're just using different timekeeping methods, which has been perfectly normal ever since the Gregorian calendar was introduced.
- Point 1) while the calculator just shows the week, the actual dates are 2000-01-01 vs 1999-12-31. The week and day of week are not important to the point I was making.
- Point 2) Easter has nothing to do with anything so please lets just ignore it. The rules for the general use Gregorian calendar are quite simple, from midnight on 1582-10-15 they began counting 24 hour days, 60 minute hours, 60 second minutes (along with the leap rules). The reason is simple math. If you calculate the earth's rotation around its axis and rotations around the sun etc the time that has elapsed will not match the same equation calculated using the Gregorian calendar. That's why the edit that you keep deleting in the Gregorian calendar article is actually somewhat important (in spirit anyway). When you calculate to the second the Gregorian calendar has fallen behind the Earth's rotation by ~11,254 seconds. UT standards and ISO 8601 correct for that mistake, just like Gregorian corrected for the ~0.002% mistake in Julian.
- Point 3) Yes it does say what timekeeping method to use, it builds up from the SI defined second through to calendar years, etc, in a very specifically defined time scale. JMJimmy (talk) 23:03, 15 August 2014 (UTC)
- Your statement "while the calculator just shows the week, the actual dates are 2000-01-01 vs 1999-12-31" is not true. When the date January 1, 2000, time 00:00 is entered into the "Gregorian calendar" section of converter you suggest (and which I use myself quite a bit through a different URL) the representation 1999-12-31 does not appear anywhere on the page. What does appear in the "ISO-8601 Week and Day, and Day of Year" is Day 6 of week 52 of year 1999. Note this date is not in the "Gregorian calendar" section. If you think ISO 8601 claims this is a Gregorian calendar date, I disagree with that reading. A secondary source seem to agree: Dershowitz and Reingold don't say the week-based calendar is the Gregorian Calendar. Can you show a case where a date stated in the modern international commerce version of the Gregorian calendar would be represented by a different date in the form YYYY-MM-DD?