Talk:ISO 8601/Archive 3

Archive 1

Archive 2

Archive 3

RFC: Does ISO 8601 use the Gregorian calendar?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

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)

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", 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", 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)

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.

I didn't follow at first, but I see what you're saying. Agreed and should be changed to reflect that. JMJimmy (talk) 18:50, 10 August 2014 (UTC)

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)

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:

1. The JPL Time Conversion Tool does not mention ISO 8601 at all
2. 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)

It's not intended to bring out the purpose of the standard, it's intended to dispel a misunderstanding about the standard. JMJimmy (talk) 16:17, 11 August 2014 (UTC)

The majority of editors commenting in the RFC say the paragraph is not needed. The misunderstanding has not been clearly stated. No reliable source has been cited to prove the misunderstanding exists. I'm therefore removing the paragraph. Jc3s5h (talk) 16:39, 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.

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.

Jc3s5h (talk) 02:03, 12 August 2014 (UTC)

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.

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 the use of Gregorian UTC in general, though does not make any requirements. ...

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)

Use the Gregorian Calendar.--Fox1942 (talk) 12:21, 30 August 2014 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

ISO 2014

ISO 2014 is a hopeless stub that could be redirected to ISO 8601#History adding {{printworthy}}. –Be..anyone (talk) 01:18, 26 April 2015 (UTC)

ISO 8601 on the Internet Archive

The Internet Archive hosts a copy of ISO 8601. Would it be a bad idea to link to it? —Bromskloss (talk) 12:57, 27 January 2015 (UTC)

Thanks for the link, but we shouldn't link to it. Unless we are 100% sure a standard is "free", then we can't link to any copy on the internet, otherwise it can cause legal actions against Wikipedia. See https://en.wikipedia.org/wiki/Talk:Conventional_PCI#OFFICE_action • Sbmeirow • Talk • 18:37, 27 January 2015 (UTC)

IMO it would be okay, because we're sure enough that it used to be freely available, because an expert on this and related topics said so. And I normally consider "say so" as bad enough for a "speedy deletion". –Be..anyone (talk) 01:26, 26 April 2015 (UTC)

Just because a publication used to be available for free from the publisher does not prevent the publisher from ending the free availability. Jc3s5h (talk) 16:21, 26 April 2015 (UTC)

It is not the job of Wikipedia to decide what is or what is not allowed on the Internet Archive. If that is an issue at all it would be between ISO and the Internet Archive. Links to this site are perfectly okay. Copyright owners can change their license for a published work, but they cannot change it retroactively for existing old copies. –Be..anyone (talk) 00:17, 27 April 2015 (UTC)

Be..anyone wrote "Copyright owners can change their license for a published work, but they cannot change it retroactively for existing old copies." Quite true. But a license to have one copy on paper, one copy on a computer in one's home to read, is a different matter than making a copy on a public website is a different matter because each reader must make a new copy on the reader's computer in order to read the document. Whether the license that allowed a site to make a document publicly available can be revoked or not would depend on the terms of the license. Jc3s5h (talk) 01:22, 27 April 2015 (UTC)

The copy on archive.org clearly states "© ISO 2004 — All rights reserved". There is nothing that suggests archive.org has permission to republish. I've removed the above link as WP:COPYLINK violation. Glrx (talk) 17:59, 29 April 2015 (UTC)

Related Standards section

I am sure that no-one has time to look up every reference in the Related Standards section, but the NIST FIPS PUB 4-2 under the US entry has been withdrawn by NIST in 2008. Link to NIST withdrawn publications listing (item is on page 2 in version of "Update 3/31/14"): http://www.nist.gov/itl/upload/Withdrawn-FIPS-by-Numerical-Order-Index-4.pdf ; Link to the Federal Register detailing it's removal: http://www.gpo.gov/fdsys/pkg/FR-2008-09-02/pdf/E8-20138.pdf . Long story short, NIST related in the FR (referring to a group of withdrawn PUBs) that their standard in PUB 4-2 was based on published voluntary industry standards, and was thus redundant to publish as a voluntary standard in official NIST documents. The ANSI standard referred to in the US line item, ANSI INCITS 30-1997 - which was also referred to in the withdrawn NIST PUB - is available from the ANSI website for a fee. — Preceding unsigned comment added by 72.215.150.161 (talk) 14:32, 12 May 2015 (UTC)

Interpretation when no time zone is Specified

The current page says "If no UTC relation information is given with a time representation, the time is assumed to be in local time."

This does not seem to be mentioned in RFC 3339 any where. The RFC 3339 spec says, "All times expressed have a stated relationship (offset) to Coordinated Universal Time (UTC)" which seems to imply differently.

Some iso8601 parsing libraries assume UTC Zulu time if no time zone is specified. I want to verify that this is correct behavior. — Preceding unsigned comment added by Ramses89 (talk • contribs) 19:07, 18 August 2015 (UTC)

ISO 8601:2004 states

4.2.2.2 Complete representations
When the application identifies the need for an expression of local time then the complete representation shall
be a single numeric expression comprising six digits in the basic format, where [hh] represents hours, [mm]
minutes and [ss] seconds.
Basic format: hhmmss Example: 232050
Extended format: hh:mm:ss Example: 23:20:50

Interpreting a time with no time zone indication after the seconds field as UTC is an error. If it were UTC, there would be a "Z" after the seconds field. Jc3s5h (talk) 20:08, 18 August 2015 (UTC)

Minus sign in time zone designators

The section "Time offset from UTC" says that time behind UTC is shown with a minus sign (U+2212). What is the source of this? I would assume that the standard uses the standard ASCII hyphen-minus (U+002D). I cannot access the actual ISO 8601 document, but http://www.w3.org/TR/NOTE-datetime uses a hyphen-minus in its description and does not mention anything about it being a non-ASCII character.Killenheladagen (talk) 18:46, 22 September 2015 (UTC)

The spec does not actually say U+2212, and I think it is poor that it would use characters outside of a minimal set, but that's only me.

From ISO 8601:2004 §3.4.1:

3.4 Characters used in the representation

3.4.1 Introduction

The representations specified in this International Standard make use of graphic characters as specified in 3.4. Note that, except for “hyphen”, “minus” and “plus-minus”, these characters are part of the ISO/IEC 646 repertoire.

In an environment where use is made of a character repertoire based on ISO/IEC 646, “hyphen” and “minus” are both mapped onto “hyphen-minus”. Representations with a “plus-minus” shall only be used in such environment if the interchange repertoire includes “plus-minus”.

...

3.4.2 Characters used in place of digits or signs

[±] represents a plus sign [+] if in combination with the following element a positive value or zero needs to be represented (in this case, unless explicitly stated otherwise, the plus sign shall not be omitted), or a minus sign [−] if in combination with the following element a negative value needs to be represented.

...

4.3.2 Complete representations

...

The following are examples of complete representations of date and time of day representations:

Basic format: YYYYMMDDThhmmss Example: 19850412T101530

YYYYMMDDThhmmssZ 19850412T101530Z

YYYYMMDDThhmmss±hhmm 19850412T101530+0400

YYYYMMDDThhmmss±hh 19850412T101530+04

Extended format: YYYY-MM-DDThh:mm:ss Example: 1985-04-12T10:15:30

YYYY-MM-DDThh:mm:ssZ 1985-04-12T10:15:30Z

YYYY-MM-DDThh:mm:ss±hh:mm 1985-04-12T10:15:30+04:00

YYYY-MM-DDThh:mm:ss±hh 1985-04-12T10:15:30+04

Glrx (talk) 15:48, 24 September 2015 (UTC)

The wording in the spec is tricky, but I believe the key is this part:

In an environment where use is made of a character repertoire based on ISO/IEC 646, “hyphen” and “minus” are both mapped onto “hyphen-minus”.

ASCII being a derivation of ISO 646 (and UTF-8 being a derivation of ASCII, etc.), "hyphen-minus" is defined as 0x2D . Therefore, anywhere that uses a long hyphen in the spec is expected to use a hyphen-minus.

HOWEVER - there are a few examples in the official copy of the ISO8601 spec that indeed use the longer hyphen. For example, in 4.2.5.2 it gives "15:27:46−05:00" an example. IMHO, this is probably a editing/printing error rather than an intentional representation. Section B.1.2 shows the same exact value, but with the short hyphen, as "15:27:46-05:00".

So, I don't believe U+2212 is valid, and should thus be removed here. In common usage in computing, I don't believe any APIs in any language or environment will understand how to parse a U+2212 character, nor would they emit one when formatting output. mj1856 (talk) 18:05, 24 October 2015 (UTC)

I interpret the spec to mean long long hyphen and minus should be used if they are available in the computing environment. The long hyphen and minus are available in Wikipedia, so Wikipedia should use the long hyphen (except when discussing when hyphen-minus is appropriate). This will serve to put our readers on notice that they must not depend on the hyphen-minus always being used as the minus sign and hyphen, which I think is a worthwhile goal. Jc3s5h (talk) 18:39, 24 October 2015 (UTC)

I follow Jc3s5h. The spec explicitly states that minus is outside of ISO 646. I take the "are both mapped" statement to mean if the environment does not support "minus", then it is mapped to hyphen. The specification is confused about the "minus-plus" ("±") character. AFAIK, the "minus-plus" character appears only in the specification but never appears in an ISO 8601 string. One could make the argument that characters outside of ISO 646 (−, ±, underlined characters) are only used to communicate specification strings and should not appear in output strings. I'm willing to listen to that argument, but my current sense is the long minus character is intended to appear in output strings.

It was stupid for ISO to specify characters without specifying their codes, but ISO did it anyway: "NOTE 2: Encoding of characters for the interchange of dates and times is not in the scope of this International Standard." WP supports Unicode, so the ISO spec wants us to use the long minus. I suspect most implementations will spit out a hyphen (using lowest common denominator); good implementations will take either.

Glrx (talk) 19:32, 24 October 2015 (UTC)

In section 3.4.2:

[±] represents a plus sign [+] if in combination with the following element a positive value or zero needs to be represented (in this case, unless explicitly stated otherwise, the plus sign shall not be omitted), or a minus sign [−] if in combination with the following element a negative value needs to be represented.

In section 4.2.5.1

It shall be expressed as positive (i.e. with the leading plus sign [+]) if the local time is ahead of or equal to UTC of day and as negative (i.e. with the leading minus sign [-]) if it is behind UTC of day.

So from the first section it's clear that ± is used to describe the spec, but not in the actual output. However it's confusing that both sections say "minus sign", while the first shows the long minus and the second shows the short one.

Still, nowhere am I seeing wording that says to use the long minus when available. Sorry, but I'm not following your interpretation of that.

Additionally, note that RFC339 explicitly only allows the short hyphen, and RFC3339 redirects here. There's also wording in this article that says:

... RFC 3339, which is otherwise a profile of ISO 8601, permits the use of "−00" ...

This would be incorrect with regard to RFC3339, as the long hyphen is not in that spec. We should at least revert that particular one. We may want to include additional wording that describes that ISO8601 is unclear about long hyphens, but RFC3339 does not allow them.

mj1856 (talk) 22:15, 24 October 2015 (UTC)

I made this change. Feel free to edit the wording if you like. Thanks. mj1856 (talk) 22:10, 25 October 2015 (UTC)

References

ISO 2014

I removed the merge request from ISO 2014: it was raised almost a year ago, and got no traction, and there's no reason not to have that article. --Slashme (talk) 06:54, 3 February 2016 (UTC)

Daylight Savings Time

"But keep in mind that "PT36H" is not the same as "P1DT12H" when switching from or to Daylight saving time."

Not true. ISO 8601 makes no mention of daylight saving time. An ISO 8601 time does not represent civil wall clock time; it represents an absolute fixed moment in time, represented as UTC with a fixed offset. Therefore, a duration represents an absolute time duration, regardless of civil wall clock changes. In my opinion this text should be removed. Any objections? StormWillLaugh (talk) 15:26, 28 June 2016 (UTC)

omit the T character

When this article says "omit the 'T' character", does it mean replace the 'T' character with empty space (which "Python package: iso-8601" says is "common"), leaving some space between the date and the time? Or does it mean remove both the 'T' character and the space it occupies, pushing the date and the time together with no space between them? --DavidCary (talk) 02:05, 10 October 2016 (UTC)

Omitting year - confusing example

In the text we have

The 2000 version allowed writing "--04-05" to mean "April 5"[14] but the 2004 version does not allow omitting the year when a month is present.

But in examples --04-05 is shown as valid. This is contradictory and therefore confusing. --176.101.148.15 (talk) 16:36, 5 December 2016 (UTC)

"Rational" time format

Perhaps my comment at https://en.wikipedia.org/wiki/Talk:Sequential_time would be useful here.

As a practical matter, (consistent with ISO 8601, I think) when I omit the 2 century digits, if clarity would be improved, I insert an apostrophe (as is common in other abbreviations) so ('now' being '170314.2123), then 20991231.23595999999, or '991231.23595999999, or just 991231.23595999999, would all represent a smidge before the 22nd century (21000101.00000000000, noting the distinction between the month & date places as numbering, rather than as counting for all the other places in the date-time).

So sometimes, I also use the leading apostrophe to flag to innocenti that this is a distinctive format for date-time, even when the century digits would make the 4-digit year more obvious. I might be too laconic, and consider the separators other than the 'decimal' point, as harmless but usually superfluous, just as they are in (all?) other numbers (ref. also to EU "," instead)
--Wikidity (talk) 01:26, 15 March 2017 (UTC)

Either a string complies with ISO 8601 or it doesn't. The standard is aimed primarily at automated interchange of dates and times, with human readability secondary. Your strings don't comply and will not be understood by automated tools that accept ISO 8601 dates and times. Jc3s5h (talk) 01:36, 15 March 2017 (UTC)