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)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on ISO 8601. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20040401234715/http://astro.nmsu.edu/~lhuber/leaphist.html to http://astro.nmsu.edu/~lhuber/leaphist.html

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 02:48, 8 April 2017 (UTC)

date examples

the examples in the infobox use current time. at time of writing: 2017-05-02T13:20:44+00:00 I believe this might be misleading, and would be best to use a fixed date, with the month number greater than 12. same might be good for hours/minutes. e.g.: 2016-12-31T23:59:59+00:00

I believe this will be easier to read and help understanding where the month/day is. — Preceding unsigned comment added by Oha.it (talk • contribs) 13:42, 2 May 2017 (UTC)

Micro seconds

It would be nice, when the article would say something about micro seconds. Is possible or is it not possible to store micro seconds in a ISO 8601 time stamp? Even if it is not possible, it is worth to be noted. --Ceving (talk) 15:37, 5 May 2017 (UTC)

Either the minutes field or the seconds field may include a decimal point (either a full stop or a comma) followed by as many digits as necessary. However, if the seconds are included, the minute can't have a decimal point or digits to the right of the decimal point. The data interchange partners must agree on the number of digits to the right of the decimal point. So if you're writing something for general use, and have no idea who is going to receive it, decimal points shouldn't be used. Jc3s5h (talk) 16:37, 5 May 2017 (UTC)

The previous answer is excessively cautious. A time expressed according to this norm as 00:00:00.000001 cannot possibly have another interpretation than one microsecond after midnight. So yes, microseconds can be unambiguously expressed. −Woodstone (talk) 12:05, 6 May 2017 (UTC)

I infer the intent of the standard is that if the parties exchanging information have not agreed to anything special, automated software can parse any valid string, without any hints, and without knowing the context. Some examples from the standard:

152746

52746+0100

15:27:46+01:00

985102T235030Z

985-102T23:50:30Z

My guess is someone figured out some situation where the interpretation could be ambiguous if the use of decimals, and the number of digits to the right of the decimal, was not agreed to in advance. If you sure the string is going to be read by a human, it's probably safe to use a decimal without advance permission. But if the string is to be parsed with software, it's safer to assume the author of the parser rigidly followed all the rules. Jc3s5h (talk) 12:18, 6 May 2017 (UTC)

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

I actually came to this article just to find the number of RFC 2550, which Google didn't find and which I'd misremembered as 2250. It's important to remember that Wikipedia is often useful as a different kind of search engine, rather than as a traditional encyclopedia. I think RFC 2550 should be referenced from the original article. Will Mengarini (talk) 21:20, 15 July 2017 (UTC) Will Mengarini (talk) 21:20, 15 July 2017 (UTC)

TIL that this client automatically signs my comments, doesn't stop me from doing so redundantly, doesn't stop me from doing so redundantly, and doesn't let me edit or delete them. Sigh. Will Mengarini (talk) 21:23, 15 July 2017 (UTC)

How to Pronounce 2017-07-28?

Does ISO 8601 specify how to pronounce a date such as 2017-07-28? We need a pronunciation that is consistent with the YEAR-MONTH-DAY order. --Roland (talk) 00:10, 29 July 2017 (UTC)

No, the standard makes no mention of pronunciation. Jc3s5h (talk) 00:15, 29 July 2017 (UTC)

Can we invent one, at least in English? --Roland (talk) 09:56, 5 August 2017 (UTC)

You can try whatever you want among your friends, and see if it catches on. But inventing pronunciations is not the purpose of Wikipedia; see WP:NOR. Jc3s5h (talk) 14:47, 5 August 2017 (UTC)

ISO 8601 cannot combine Weeks (W) and other designators?

In the aticle, under ISO 8601 durations it mentions:

Durations are represented by the format P[n]Y[n]M[n]DT[n]H[n]M[n]S or P[n]W as shown to the right.

I think should be: Durations are represented by the format P[n]Y[n]M[n]W[n]DT[n]H[n]M[n]S or P[n]W as shown to the right.

Tiny difference, but the point being that Weeks are allowed in the standard.

I could not find any mention of them NOT being allowed, and I would like to challenge you to come up with ANY good, valid reason to not allow them.

Granted, there are no examples that I could find that have weeks included. Amongst others, I looked here:

• in the W3C document there is no mention of something like "1Y2W" being disallowed.
• In the ISO standards document (page 9) it gives an example very similar to how it's written on Wikipedia, but also it is not said to be disallowed.

It seems like ISO 8601:2004 , has gotten rid of the example of W in durations altogether. So I'd also be fine with removing that W (and example) altogether. — Preceding unsigned comment added by ThatcherP (talk • contribs) 20:37, 15 August 2017 (UTC)

And for your enjoyment: https://xkcd.com/1179/

ThatcherP (talk) 19:31, 15 August 2017 (UTC)

References

Software implementations

Discussion:
This page is supplementary to the authority of ISO 8601.
Providing a standard use for the language saves the developer time; ensures consistency; reduces errors.
Encyclopedias are tertiary sources of information (as opposed to primary). However this is referencing the framework.
I advocate adding a section for software implementations, as it is most expected that ISO 8601 is to be processed by a computer and not a human by hand.

Kotlin (Android):
val simpleDateFormat = SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSS'Z'", Locale.UK)
simpleDateFormat.timeZone = TimeZone.getTimeZone("UTC")
simpleDateFormat.parse(value)

Example data:
val value = "2017-10-23T20:53:49.078Z"
Gedium (talk) 20:46, 11 January 2018 (UTC)

Zulu time

User 108.161.123.51 removed the following text from the article:
UTC time is also known as Zulu time, since Zulu is the NATO phonetic alphabet word for Z.
with the following comment "GMT/UT are known as Zulu time not UTC".

The letter Z is a part of the ISO8601 standard and Zulu is a NATO phonetic for the letter Z. However it might be true that "Zulu time" means more than just "Zulu + time" and is more specific than a zero offset in any time system. I don't know if "Zulu time" is really limited to GMT/UT or not. Military time seems to be bound to UTC nowadays and "Zulu time" is still there so while it was GMT-only in the past it probably applies to UTC now. In any case I don't think choice of letter "Z" in ISO8601 is a coincidence, so it should be mentioned but probably with a different wording. If anyone has a reliable source to clarify what exactly "Zulu time" means and used to mean in the US military and other spheres please share it. Salmin (talk) 19:13, 12 June 2017 (UTC)

Zulu time is a military timescale used by some countries. It varies from UTC and from country to country. There's SO much bad information out there on the subject it's nearly impossible to find the truth. The truth is that Zulu and UTC both share the prime meridian as the starting point. From that people do the "Zulu time = GMT = UTC" inappropriately. The US military as an example does not use the standard time zone map so there are differences. If memory serves, Algeria or part of it, normally considered UTC+1, is Zulu time or UTC+0. There are many other small differences but the details are lost on most people. 108.161.123.51 (talk) 18:45, 14 August 2017 (UTC)

Algeria is an interesting case, but the ISO8601 doesn't seem to care much about geography or particular assignment of time zones. It just gives a way to express a time with a given offset from UTC. Anywhere on Earth I can say that the current UTC time is "X". The same applies to "Zulu time", you don't need to be in London to state that the current "Zulu time" is "Y". Then, if it turns out that at any given moment of time "X" is always equal to "Y" then it would be correct to say that "Z" in ISO8601 nowadays designates the "Zulu time" under the current definition of "Zulu time". The caveat is that this definition was different in the past and might change in the future. Salmin (talk) 06:56, 15 January 2018 (UTC)

It seems you were right, the ACP 121 standard clearly says that "Zulu time" is GMT and makes no mention of UTC at all. I'll update the article accordingly. Salmin (talk) 10:35, 15 January 2018 (UTC)

GMT and UTC are not equivalent, and are allowed to differ by as much as 0.9 seconds, unless BIPM have changed the rules. 94.30.84.71 (talk) 19:04, 6 January 2018 (UTC)

This is certainly true, but the question is whether "Zulu time" is bound to GMT or UTC nowadays. If it's UTC then this should be mentioned in the article. Otherwise associating "Z" from ISO8601 with "Zulu time" is a widespread mistake which again should be mentioned in the article with an appropriate wording. Salmin (talk) 06:21, 15 January 2018 (UTC)

My copy (version 2004) of the standard states: "2.1.14 standard time - time scale derived from coordinated universal time, UTC, by a time shift established in a given location by the competent authority". So the addition Z to a time makes it UTC. −Woodstone (talk) 09:30, 15 January 2018 (UTC)

This is correct, the "Z" letter in ISO8601 clearly means "UTC". Though it doesn't mean we can call it "Zulu time" because "Zulu time" means more than simply "Z + time", it's a specific military time zone. I've found a 2010 version of the ACP 121 standard and it still makes no mention of "UTC". Instead it states: "The lower figure in each block represents the comparative time in the Ø zone, Greenwich Mean Time or Greenwich Civil Time. This time is sometimes referred to as “GMT” or “GCT”, but more frequently, is known as “Zulu” time." So I guess this seems to be settled for now, just need to put that info into the article correctly. Salmin (talk) 10:29, 15 January 2018 (UTC)

When wording your correction, bear in mind that the scientific community that provides precision time units only pays attention to well-defined names for time scales, such as UTC, UT1, or International Atomic Time. "GMT" is not well defined and sometimes refers to UTC, other times to UT1. If you ask the scientific community what "GMT" means, they'll just say it's an obsolete term and you shouldn't be using it. Jc3s5h (talk) 15:56, 15 January 2018 (UTC)

Well I did my best to reflect that in the article. Feel free to fix the wording if I've missed something. Also note that Zulu time is a redirect to a section in the Coordinated Universal Time which says: "Since the NATO phonetic alphabet word for Z is "Zulu", UTC is sometimes known as "Zulu time"." I guess it should be corrected as well. Another source of confusion are aviation docs, e.g. the NOTAM which states that "Times used in the NOTAM system are Coordinated Universal Time (UTC/Zulu) unless otherwise stated". This is cited in the wikipedia article but it's correct in a sense that the standard does actually say that. Probably the Coordinated Universal Time article should assemble and annotate all this information and other places have a link to it. Salmin (talk) 21:09, 15 January 2018 (UTC)

I have created bit encoding for all ISO 8601 date, time and timezone basic formats.

anyone interested in helping to standardize the bit encoding so ISO 8601 basic format becomes universal like:

   · UNICODE (ASCII).
   · 2's complement binary at 8, 16, 32 and know 64 bits.
   . IEEE 754 floating point.  

It supports the largest date range (±9999) smallest time precision (fraction of seconds to 16 digits). Oracle supports minus dates and NASA and IBM support fraction of seconds to 12 digits. The arithmetic is 5x to 15x faster than any other date/time. It is pluggable into most languages. The first bytes contains metadata that identifies if the date/time is:

   · Date is yymd, yyddd, yywd.  I support day of era necessary for conversion to calendars of other nationalities (Jewish, Muslim). 
   · Time is hmsfff, hmffff, hfffff, ffffff (fraction of day is not ISO 8601)

The arithmetic uses the same instruction (common instructions):

   · For addition and subtraction using complement arithmetic.
   · For all date format and time formats (it does not convert to a common format, like the Gregorian date).  

It uses the ISO 8601 duration format (±nYnMnDTnHnMn.nS) that has been expanded to support day-of-year (ordinal) and week-of-year. To support events, like Memorial Day and Labor Day, the duration has been expanded.

   · =5m5w1d  5th month, 5th week (last week of month, last 7 days) 1st day (Monday).
   . =9m1w1d-1d Sunday before labor day (I permit + or - before any element.    
   · =11m4w4d Thanksgiving
   . =est      use an algorithm for Easter. 
   · =3m2w7dt2h start of daylight 
   · =5w5d9h     A meeting the last Friday of the month

Note! these work also for day-of-year and week-of-year.

I support HR-XML 2007 exceptions and options:

   .  Date is not applicable 0000-00-00 date of marriage for a single person.
   ·  Date is not known      9999-99-99 date of termination for existing employees.

I store dates and BID (binary integer decimal).

   .  8 bytes store era, centuries, years, months, days, hours, minutes, seconds.
   .  8 bytes store 16 fractional digits.  

Hjwoudenberg (talk) 04:17, 8 February 2018 (UTC)

The purpose of Wikipedia talk pages is to discuss how to improve the article. They is not for general discussion about the topic of the article. Jc3s5h (talk) 14:08, 8 February 2018 (UTC)

Box, upper right, error?

Box, upper right, contains "Date without year: --01-06" - I think that the leading hyphen is a mistake. I believe that the standard contains 280 instances of '-', but none of '--'. 94.30.84.71 (talk) 19:13, 6 January 2018 (UTC)

I have a copy of ISO 8601 and cannot find any provision for representing the month and day but omitting the month. Therefore I have removed this line from the box. Jc3s5h (talk) 16:55, 7 January 2018 (UTC)

Yes, it was in ISO8601:2000 (obsolete). zelenin (talk) 19:06, 7 January 2018 (UTC)

And is still in modern/current use in RFC 6350 (vCard) which makes it worth keeping in the box. Edited to clarify last in ISO8601:2000 (to reduce confusion) and in current use. Hopefully that's notable enough to keep it. Tantek (talk) 00:06, 22 February 2018 (UTC)

hhmm zone offset out of spec?

The section on time zone designators suggest ISO 8601 allows an offset without a colon:

<time>±hhmm

After reviewing the ISO 8601-2 pdf, it appears that this may not be allowed. Section C.1.3.2 says:

"Zone-offset may be omitted or included. Time zone designation consists of either a 'Z' to indicate UTC, or a '+' or '-' to indicate "ahead of UTC" or "behind UTC", followed by a 2-digit hour, followed optionally by a colon and the 2-digit minutes."

Many implementations of ISO 8601 seem to allow the colon to be omitted, but maybe this is a common misconception. Can anyone cite where the hhmm offset came from? — Preceding unsigned comment added by 192.206.204.10 (talk) 19:07, 2 March 2018 (UTC)

a) You refer to the draft, not accepted standard. b) You refer to the extended profile, not basic.

See 4.2.1 ISO/WD 8601-1 pdf

zelenin (talk) 21:18, 2 March 2018 (UTC)

Great! Thanks for providing the reference, section 4.2.5.2 explicitly shows hhmm offsets are allowed. I'd like to suggest linking the iso8601-1 pdf in the article so it is easier to find. 192.206.204.10 (talk) 17:51, 6 March 2018 (UTC)

A suggestion on ISO date format

Greetings, everybody, I don't know how to suggest this to the ISO, but I don't know how they missed it. The date format standardisation is yyyy-MM-dd, which is good for clearing the confusion between the dd-MM-yyyy and MM-dd-yyyy formats. But, as an Arabic speaker, it's very frustrating. Because of you typed it on computer, it shows in reverse, for the "-" is flexible to RTL and LTR directions, unlike other marks or the ".". And if I typed it the normal Arabic way it shows right, but it loses its sorting advantage. So I suggest the format yyyy.MM.dd for the mentioned reason and another one, it doesn't break at the end of a line. Best Regards Abu-Ghadeer ؛؛؛؛

AhmedAbuGhadeer (talk) 08:02, 29 May 2018 (UTC)

This talk page is for discussing how to improve this Wikipedia article. Suggestions for improving the standard are out of scope. I don't know how to suggest changes to the standard either. Jc3s5h (talk) 09:36, 29 May 2018 (UTC)

Leap Seconds

I came hear after reading some code that supposedly conformed with ISO 8601 but didn't support the 61st second on days that had them. After reading the draft it appears that this page is wrong. (Maybe older versions of the standard are different?) 199.64.6.155 (talk) 14:51, 27 June 2018 (UTC)

As it says in this article, "The standard does not assign any specific meaning to elements of the date/time to be represented; the meaning will depend on the context of its use." It's possible the code is representing some version of time that does not include leap seconds.

Could you quote the passage in this article that you think is wrong? Could you also specify what drat you read (and if the draft is more than a page long, specify what page, or give a quote we can search for)? Jc3s5h (talk) 15:12, 27 June 2018 (UTC)

Need explain how to express current time

When <start>/<end> have no "end time" because is a the current time, and will not change. See https://stackoverflow.com/q/48696238/287948 about next ISO version. — Preceding unsigned comment added by Krauss (talk • contribs) 14:25, 20 July 2018 (UTC)

Timezones and UTC offsets are NOT the same thing

"(with optional time zone information; e.g., the UTC offset)"

Sorry but timezone and utc offsets are NOT the same. I see this mistake committed all the time and leading to problematic bugs. An UTC offset is just that. An offset from the UTC time, which does not specify when it is applicable. A timezone is a set of rules that determine when along the time the offset is applied and if there is daylight switch somewhere. Obviously timzone conveys a totally different piece of information than just an offset. — Preceding unsigned comment added by 94.32.208.151 (talk) 07:41, 16 October 2018 (UTC)

YYYY-MM-DD vs YYYY-DD-MM

Depending on the current date the Infobox examples are ambiguous.

Ideally always show both the abstract format and the example date:

2019-03-06 (YYYY-MM-DD)

Ideally use examples where DD is > 12 to automatically avoid confusion with months.

Nothing ambiguous here. The standard is very explicit that it only considers month before day. Furthermore, to it is very unlikely that a format like YYYY-DD-MM is used anywhere in the real world at all. −Woodstone (talk) 16:57, 7 March 2019 (UTC)

Removed bogus claims about hypen/minus differences.

I have removed this paragraph from the article:

→ISO 8601 permits the hyphen (-) to be used as the minus (−) character when the character set is limited. In contrast, RFC 3339 explicitly requires the hyphen (-) symbol to represent negative offsets and does not allow for use of the minus (−) symbol.

I don't know where this is from, but it's certainly not covered by the sources, and clearly wrong: ISO 8601 explicitly moves character encoding and character set out of scope, and mentions that ISO 646 maps both hyphen and minus to the same character (as does unicode btw.). To confuse things more, the character displayed in the article as the alleged "hyphen" depends on the browser, and might be a hyphen, minus, or minus-hyphen.

Similarly, RFC 3339, by using ABNF, specifies the hyphen-minus character, which stands for either the hyphen or minus.

While there might be differences between those two standards, the original paragraph is demonstrably wrong and not covered by the sources. 82.212.59.114 (talk) 05:56, 22 March 2019 (UTC)

References

Revised specification arrived: ISO 8601:2019

Please see https://www.iso.org/standard/40874.html Kuldeepdhaka (talk) 11:06, 27 March 2019 (UTC)

HH 24 hour times vs hh 12 hour times

Most systems I have worked with since 1995 designate 24 hour clock settings as 'HH' and 12 hour clock settings as 'hh,' to help differentiate the styles when adjusting system settings, but this article uses 'hh' as the 24 hour designation. Should this be changed? DocKrin (talk) 06:10, 4 May 2019 (UTC)

The ISO 8601 standard uses hh so this article should too. In the context of ISO 8601, the need to choose between 12 hour clocks and 24 hour clocks does not arise. Jc3s5h (talk) 13:51, 4 May 2019 (UTC)

Update article

This article needs an update. The latest version of ISO 8601 was published February 2019, which "cancels and replaces ISO 8601:2004" according to their website. I have a draft I obtained earlier from their website labeled ISO/DIS 8601-1:2016(e). Its section 2.3.7 states "representation with reduced precision", so accuracy/precision becomes a non-issue. Simply change "accuracy" to "precision", and remove any associated double quotes as well as the explanatory note from the article. The rest of the article needs to change any mention of proposed changes to actual changes from ISO 8601:2004 to ISO 8601:2019. I do not have a draft of the new part 2, nor can I find any drafts of parts 1 or 2 remaining on their website. But I do find an explanation of the changes to ISO 8601 by Klaus-Dieter Naujok. — Joe Kress (talk) 21:17, 27 August 2019 (UTC)

Inclusivity of intervals (and durations)?

The examples given are not consistent:

• 「a two-hour meeting including the start and finish times could be simply shown as "2007-12-14T13:30/15:30"」 and 「2007-03-01T13:00:00Z/2008-05-11T15:30:00Z」 indicate it’s inclusive-beginning, exclusive-end
• 「a monthly billing period as "2008-02-15/03-14"」 indicate it’s inclusive-beginning, inclusive-end

The inclusivity of the beginning is likely granted, but I’m very much interested in the inclusivity of the end. From working with things like iMip, I think they are normally exclusive-end, so that the billing period would need to be “2008-02-15/03-15”.

What does the actual standard say?

mirabilos (talk) 14:22, 20 December 2019 (UTC)

I participated virtually in a US Library of Congress discussion group about the extended version of the standard, and in connection with the discussion, was given a 2016 PDF version of the standard that was intended to be the same as the 2004 version of the standard. It has this to say:

2.1.3

time interval

part of the time axis limited by two instants

[IEC 60050-111]

Note to entry: A time interval comprises all instants between the two limiting instants and, unless otherwise stated, the limiting instants themselves.

I am not at liberty to distribute the copy I have; you would have to buy a copy of the official standard. Jc3s5h (talk) 17:03, 20 December 2019 (UTC)

An equivalent note can be seen at the ISO website at ISO 8601-1:2019 at §3.1.1.6. — Joe Kress (talk) 20:57, 20 December 2019 (UTC)

My copy of ISO/DIS 8601-1:2016(e) which used to be available at the ISO web site has the same entry quoted by Jc3s5h. — Joe Kress (talk) 21:12, 20 December 2019 (UTC)

I guess that they moved everything that was in §2.1 of the draft version to §3.1 of the final version, slightly reworded. — Joe Kress (talk) 21:25, 20 December 2019 (UTC)

2020-02-02

Today is the first ever palindromic ISO8601 date with no odd digits. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:49, 2 February 2020 (UTC)

Article date format

What date format should this article use? It is currently inconsistently using YMD and DMY alternatively in its prose; which one should be picked? YMD for the relevancy? Or DMY for the normalcy?  Nixinova   T   C   07:53, 28 February 2020 (UTC)

My suggestion is to use the YMD (YYYY-MM-DD) format throughout the article. Unfortunately, while we have {{Use dmy dates}} & {{Use mdy dates}} templates, we do not yet have {{Use ymd dates}} or {{Use ISO dates}} templates. The latter would be useful here & elsewhere. Peaceray (talk) 16:39, 28 February 2020 (UTC)

At a minimum, conventional dates will have to be used to explain ISO 8601 dates. Jc3s5h (talk) 17:12, 28 February 2020 (UTC)

"Year Zero"

It is unbelievable that educated people cannot distinguish between a period of a given order of magnitude, e.g. days, years, etc., on the one hand, and a point in time at the zero crossing, here "0". As is well known, zero means "nothing". Zero is a number without contents. Sad! 2A02:8108:9640:AC3:58DD:D222:61CF:28D (talk) 08:04, 13 April 2020 (UTC)

Why the ISO8601 does not allow three letter strings for month?

Does anyone have any insight or suggestions on the logic behind why the ISO 8601 does not permit to write three letter abbreviations for months, i.e. 2020-APR-14 or 2020 Apr 14 instead of 2020-04-14? Is it to be language neutral, have easier data interchange, or for some other reason? This would have seemed to make the date more readable, especially for users accustomed to other date formats like DD.MM.YYYY or MM/DD/YYYY. While the name of the months are indeed different across many languages, the names are often surprisingly quite similar, but more importantly the first three letters are often shared by many languages. Sauer202 (talk) 23:12, 13 April 2020 (UTC)

I don't know if any rational for the decisions was ever published. It occurs to me that many sorting processes that are not specifically designed to work with ISO 8601 will successfully sort the all-numeric format, but would fail if abbreviated names like APR or SEP were allowed. Jc3s5h (talk) 23:25, 13 April 2020 (UTC)

That makes sense. I wrote a note about this in the article under General principles. Sauer202 (talk) 15:10, 17 April 2020 (UTC)

It is an international standard, so language independence is important. The similarity of names is limited to only some western languages. Enormously many speakers have a language that does not use the Latin alphabet and so the month names are not similar. The lexical sorting is a bonus, created by the logic of ordering from large to small parts. However, describing what the standard does not allow, is not a task for this article. −Woodstone (talk) 12:23, 18 April 2020 (UTC)

Times: “24” no longer allowed

In the section “Times” the first bullet point states that the hour component ranges from “00” to “24” (with the caveat that “24” is used in only a particular circumstance).

This was certainly true in ISO 8601:1988 (section 5.3.2) and ISO 8601:2004 (section 4.2.3), and I presume all editions in between. But it is explicitly disallowed in 8601:2019 (section 5.3.2).

Since use of “24” as an hour indicator is explicitly disallowed by the most recent edition, and because it is an exceedingly bad idea, I think the bullet-point should be reworded. If people think a nod to the shameful history is important, it should be relegated to a footnote.

And, correspondingly, shortly thereafter, the paragraph starting with “Midnight” needs to be re-written. That is, the article should not say “A or B may be used except if you are using the newest version, in which case only A”, but rather should say “A is used. (Earlier versions allowed B, too.)”.

Moreover, since (the crazy) “24:00” is not being used, midnight is no longer a special case.

Thus perhaps:

Midnight should be referred to as "00:00". (Earlier editions of the standard also permitted "24:00", noting that "2007-04-05T24:00" is the same instant as "2007-04-06T00:00".) The notation "00:00" is used to indicate the very beginning of a calendar day. (see Combined date and time representations below).

Sbauman (talk) 18:48, 5 September 2020 (UTC)

Range of values permitted by ISO 8601 for time zone offsets

Does ISO 8601 say anything about the permissible range of time zone offset values? For example, it is plausible that the range might be +12 hours to -12 hours, or it might be +24 hours to -24 hours, or it might be something else entirely. I have been hunting around for clues but I have not found any clear statements about this. I am aware that actual time zone offsets range from +14 hours to -12 hours, but I don't think that necessarily implies anything about the ISO 8601 date/time format. Thanks for any information. 216.161.55.95 (talk) 22:01, 17 November 2020 (UTC)

In popular culture?

I recently stumbled upon this XKCD, and I wonder if an "In popular culture" section including that XKCD is appropriate? It is not custom on this type of page to include an "In popular culture" section so I would understand a "no" but it is still mentioned in some form of popular culture.

What are your thoughts?

I'm not a seasoned Wikipedia editor so I might have missed something which clearly points in any direction.

P.S. I'm a XKCD fan so my objectivity on this subject could be questioned.

Gositi (talk) 12:11, 20 November 2020 (UTC)

"In popular culture" sections are usually a bad idea, and particularly so in technical articles. Jc3s5h (talk) 13:13, 20 November 2020 (UTC)

Agreed. "In popular culture" sections really don't add anything to technical articles that can't be found with a simple search. I'm an XKCD fan, too; see https://xkcd.com/446/ for a mention of this topic (be sure to read the alt-text). — UncleBubba ^{( T @ C )} 21:33, 17 December 2020 (UTC)

Mention that there is no "affordance format"

Many online services use a helpful additional "affordance format". E.g. JIRA uses the following:

• 3 days ago
• Yesterday
• 1 hour ago
• 2 minutes ago
• Just now

Can the article mention that this is not part of the standard, and also mention what this is called? I assume "affordance format" is not the formal term. Can the article also mention that weekdays ("Mon", "Tue") are not allowed? — Preceding unsigned comment added by Bjornte (talk • contribs) 11:29, 17 December 2020 (UTC)

Unix uses these so-called relative forms, too, and I don't think a mention is warranted here, because ISO8601 dates are mostly numeric, and Unix relative dates are not. I don't think anyone is going to confuse the two. — UncleBubba ^{( T @ C )} 21:45, 17 December 2020 (UTC)

Can date have time zone info?

I see no example of date with time zone, eg. 2020-11-08Z or 2020-11-08+01:00 (this implies a date has a time of 00:00). Not sure if this is legal in ISO 8601? I know DateTime\DateTimeOffset in .NET will successfully parse it thou, and I get tons of hits on Google "yyyy-MM-ddZ". This seems to be a weakness in the standard, I think it should have been specifically disallowed if not legal. — Preceding unsigned comment added by 148.252.106.136 (talk) 23:03, 8 November 2020 (UTC)

It could be useful to have info about this in the main article. — Preceding unsigned comment added by Osexpert (talk • contribs) 15:11, 8 November 2020 (UTC)

At least at the time of writing this, the article does have a second-level section titled "Time zone designators", which has many examples of the kind you wished for. Teemu Leisti (talk) 14:01, 31 December 2020 (UTC)

Teemu Leisti, I think you missed the point of the original post. Does ISO 8601 allow a representation like 2020-11-08+01:00 which has no indication of the time of day? For example, if I read a newspaper article that said an event occurred 11 November 2020 in Paris, France, without giving the time of day, I could represent it as 2020-11-08+01:00, if that is a valid representation. Jc3s5h (talk) 14:39, 31 December 2020 (UTC)

You're right, I didn't read the question carefully enough and missed the point. I googled a bit, and found this question [6] in Stack Overflow. The consensus of the answers is that the standard does not allow for adding a timezone to a date without a time component. Teemu Leisti (talk) 15:19, 31 December 2020 (UTC)

Would it be useful to define what a day/month/year consist of?

I was reading this line in Durations :

Thus, "PT36H" could be used as well as "P1DT12H" for representing the same duration. But keep in mind that "PT36H" is not the same as "P1DT12H" when switching from or to Daylight saving time.

And thought "Surely a day is defined as 24 hours and 12 hours is 12 hours, so why would changing daylight savings matter?"

But presumably a day is defined like "the next occasion when the time is greater than current time" ? Meaning 1 day per year is 23 hours long and one is 25.

And then considered months/years, month is the next occasion when the day is the greater (or month number more than 1 different), and a year the next occasion where the month+day are greater.

Seems like it would be useful information to be added to the page. (probably needs to be worded better than that and not just a guess!)

I just added some discussion that durations are calendar days, months, and years. In the context of intervals, this is well defined. But a "pure" duration with years or months is ambiguous regarding the amount of time in such a "pure" duration. --netjeff (talk) 21:12, 1 April 2022 (UTC)

I think if you are at 6pm on the eve of daylight savings, and add 1D, you end up at 6pm the next day.

Whereas if you add 24H, you end up at either 5pm or 7pm (depending on whether the clocks go forwards or backwards) 77.119.223.171 (talk) 22:59, 27 April 2022 (UTC)

When the day of the month is omitted

When the day of the month is omitted the only format is allowed is YYYY-MM, but YYYY-MM can sometimes be confused by a range of years, but using YYYY-MM-- actually would be the best way to write it

A single date (1906 August 4)

Basic format: 19060804
Extended format: 1906-08-04

Well writing 190608 could mean 1906 August or 2019 June 8 or even (1919 June 8)

1906-08 could mean 1906 August or even it can be a timespan expanding from 1906 to 1908, so writing a format like 1906-08-- is the most appropriate way to write the date

ISO 8601:2000 permitted to write the format in --MM-DD, because writing it in MM-DD could mean a lot of things it could be confused with DD-MM, MM-YY or even YY-MM or a range of years 98.31.29.4 (talk) 21:14, 29 July 2022 (UTC)

Limitations / Criticism

Perhaps add a few words about the limitations of the format. Something like:

Precision when interpreted as an unambiguous point on a time-line

In its full form (including time zone information), the format can accurately represent a past instant. For example, the value 2020-05-25T22:56:19.782Z is a an accurate representation of a past instant of which there can be no ambiguity.

However, for future instants the format lacks precision power. Consider, as an example, a contract that says that "delivery must made at the latest on 30th of June, 2035, at noon in Chicago, US". This cannot be modeled by ISO-8601. The way to express it by ISO-8601 would be as 2035-06-30T12:00:00-05:00 or as 2035-06-30T17:00:00Z. There are two problems with this:

• It is unknown if Chicago in 2035 will observe Daylight Savings Time or not. Governments change DST rules at will.
• It is unknown if Chicago in 2035 belong to the GMT-5 timezone or not. Governments change timezones for locations at will. For example, the US government can decide to use only a single timezone for all the USA.

Thus, for ISO-8601 to have adequate precision power for future instants it would need to support a time zone designator such as IANA Timezone id. For example the Chicago example would then become 2035-06-30T12:00:00America/Chicago

Too much format flexibility

When used as a data interchange format for computers there is simply too much flexibility. This is to some extent mitigated by some of the many profiles based on ISO-8601 but they typically do not address all concerns. Examples of where the ISO-8601 format would need to be "narrowed" in order to work better as an interchange format for computers:

• Only allow upper-case 'T' as the separator between date and time.
• Only allow upper-case 'Z' as the time zone designator for UTC.
• Only allow dot as seconds fraction separator.
• Only allow 00:00 for midnight, never 24:00
• Only allow up to 9 decimal digits on the seconds fraction. Dealing with "unlimited" is not easy to work with for computers.
• Only allow seconds 0-59. For a computer, the value 60 (leap second), rarely makes sense anyway.

I think the problems arise from the desire to be human-readable for people from many cultures.

There is at the moment (Sept 2022) no known profile which addresses all ambiguity concerns. This is to say that ISO-8601 derived profiles meant for data interchange - even with their best intentions - inherit the ambiguity embedded in ISO-8601. Lbruun (talk) 13:27, 12 September 2022 (UTC)

YYYYMM not allowed to be used, use YYYY-MM-- instead of YYYY-MM to avoid confusion with a range of years?

When the day of the month is included (year month day), both YYYY-MM-DD for the extended format and YYYYMMDD for the basic format can be used.

But if the day of the month is omitted (year and month only), only YYYY-MM can be used, disallowing dates of YYYYMM, the standard often avoids confusion with YYMMDD to be used, YYYY-MM can easily be confused with a range of years, so I recommend to use YYYY-MM--.

So for an example both 1981-04-05 for the extended format and 19810405 for the basic format can be used.

So for an example if the day of the month is omitted, then only 1906-08 is allowed, as 190608 could be 1906 August or 2019 June 8 or even 1919 June 8, however 1906-08 could be confused between August 1906 and from 1906 to 1908. So I recommend to use 1906-08--.

You know when the year (YYYY) is omitted it's --MM-DD not MM-DD, so when the day of month (DD) is omitted should it be YYYY-MM-- rather than YYYY-MM. 98.31.29.4 (talk) 23:54, 3 October 2022 (UTC)

The --MM-DD format (and related formats -YY-MM, -YY, --MM, ---DD, etc.) haven't been permitted for 18 years.

Additionally YYYY-MM-- is a complete fabrication and does not appear anywhere is either part of the standard IJMacD (talk) 08:07, 9 October 2022 (UTC)

Well YYYY-MM can easily be confused with a range of years, but your right about the part where the formats YY-MM-DD, --MM-DD, and the related formats -YY-MM, -YY, --MM, and ---DD, does ISO 8601 even allow to omit the day of the month anyway?, just to display month and year, I know a format YYYYMM is not allowed due to ambiguity.

190402 could mean 1904 February or 2019 April 2, so a format like 202405 is ambiguous, but if the full date is included then 20240526 can be used for the basic format, whereas 2024-05-26 is used for the extended format. 98.31.29.4 (talk) 20:10, 6 November 2022 (UTC)

YYYY-MM (with -) is specifically allowed in § 5.2.2.2 Representations with Reduced Precision. (As are YYYY for year; YYY for decade; and YY for centrury)

YYYYMM (without -) is specifically prohibited by § 5.2.2.2; not primarily because it could be confused with non-ISO 8601 formats but because it could be confused with hhmmss.

hhmmss (without a leading T) is specifically given as a valid example in Table A.9 of Annex A.

Within the standard there's no confusion with range of years since ranges are specified with / (see § 5.5.1) e.g. 1906/1908. I realise that it may be confused for formats outside the standard though, however this is ironically something that ISO 8601 doesn't really put much emphasis on. IJMacD (talk) 03:04, 10 November 2022 (UTC)

Local time

"Time zones in ISO 8601 are represented as local time (with the location unspecified), as UTC, or as an offset from UTC."

This I would like to update this statement as we had a misunderstanding. I propose:

Time zones in ISO 8601 are represented as local time (without a zone designator), as UTC with append 'Z' zone designator, or as a local time with an append UTC offset. Mrdvt92 (talk) 17:13, 13 February 2023 (UTC)

I would write something like

Times in ISO 8601 are represented as local time (without a zone designator), as UTC with appended 'Z' zone designator, as UTC with an appended 0 offset, or as a local time with an appended offset from UTC.

Jc3s5h (talk) 18:21, 13 February 2023 (UTC)

Local time (unqualified)

"If no UTC relation information is given with a time representation, the time is assumed to be in local time." Where is the source for this? RFC3339 requires either a 'Z' or "+-hh:mm". In my opinion, it would be safer to assume UTC, if the timezone is missing. Local time in international internet communication makes no sense at all. 165.1.191.123 (talk) 11:49, 9 January 2023 (UTC)

"Date and Time on the Internet: Timestamps" (RFC 3339) is about date and time on the internet. It does indeed say

A number of devices currently connected to the Internet run their internal clocks in local time and are unaware of UTC. While the Internet does have a tradition of accepting reality when creating specifications, this should not be done at the expense of interoperability. Since interpretation of an unqualified local time zone will fail in approximately 23/24 of the globe, the interoperability problems of unqualified local time are deemed unacceptable for the Internet.

But ISO 8601 is a superset of RFC 3339. ISO 8601 does allow unqualified local time. Presumably people using unqualified local time would communicate the details of the local time in some way other than writing it in a way recognized by ISO 8601. For example, it might be specified it is whatever local time is in force in Dublin on some future date. I have seen this in earlier versions of ISO 8601 but I do not possess the latest version of the standard. Jc3s5h (talk) 18:57, 9 January 2023 (UTC), Clarified 10 February 2023 16:56 UTC.

OK, thanks. Digging through some second hand sources (links below the article) confirms this. Still a shame that such standards are not publicly available... 165.1.187.221 (talk) 08:56, 10 January 2023 (UTC)

In contrast to IETF RFCs, many ISO standards (such as this one) are not specific to Internet usage, nor necessarily to even computing in general.

Based on the discussions regarding the creation of the new EDTF code extension in 8601-2019, ISO 8601 dates appear to be used by such diverse professions as librarians, astronomers, historians (where the exact time zone may not be known, because the location of the event was not known, or where they pre-date the introduction of time zones themselves; e.g., when cataloging the personal diary of a notable figure), publishers, accountants, and even administrative staff (e.g. recording ‘call the Director at 9 a.m. local time, wherever she happens to be that day’, when the location is not available at the time of data entry or irrelevant.)

- Jim Grisham (talk) 16:52, 9 March 2023 (UTC)

> Where is the source for this?

The source for this, along with most of the rest of the article, is ISO 8601. Specifically it is § 5.3.1 Local time of day.

This is the Wikipedia page for ISO 8601, not RFC 3339; therefore RFC 3339 is not relevant. There's no need to assume anything. This article must be a factual representation of what's written in the standard.

Furthermore, as others have pointed out, the internet is not mentioned once anywhere within the document. ISO 8601 formats are perfectly applicable to communicating dates and times between two colleagues in the same building using their local time.

- IJMacD (talk) 08:03, 24 May 2023 (UTC)

Negative durations

It seems negative durations are not defined in the standard. (At least this archived comment says so, and they're not mentioned here.) But .ics files for Google calendars use them e.g. for VALARM as in TRIGGER:-P0DT0H30M0S. Is this worth mentioning here? ◅ Sebastian 10:19, 28 May 2023 (UTC)

Durations are defined in ISO 8601-1:2019 to be non-negative.

3.1.1.8 duration
non-negative quantity of time equal to the difference between the final and initial instants (3.1.1.3) of a time interval(3.1.1.6)

I guess sort of like how speed is just the magnitude of a velocity in an arbitrary direction; ISO 8601 durations are just the magnitude of difference between two instants in time.

To specify 30 minutes before a date-time you could use the following syntax:

PT30M/2023-05-30T12:00

However, ISO 8601-2:2019 allows negative component values in durations e.g. P-3DT-30M.

It also allows a negative sign '−' to appear before the P prefix.

EXAMPLE 7 '−P2M1D' is equivalent to 'P−2M−1D'.

So it appears Google Calendar .ics files are indeed compliant with ISO 8601, (specifically ISO 8601-2:2019 §11.3.2).

IJMacD (talk) 04:36, 30 May 2023 (UTC)

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

-- (unsigned) 2003-03-01T12:06:42‎ MartinHarper

It appears that it's rapidly becoming a de facto standard (if not yet de jure) at least for dates in Wikipedia citations.

— Preceding unsigned comment added by 67.52.192.26 (talk • contribs) 21:05, 11 February 2014 (UTC)

Are the Period gaps correct

interval 2003-02-15T00:00:00Z/P2M ends two calendar months later at 2004-03-15T00:00:00Z which is 59 days later

interval 2003-07-15T00:00:00Z/P2M ends two calendar months later at 2004-03-15T00:00:00Z which is 62 days later

Is this really correct?

I might be missing something, but surely 2003-02-15/P2M -> 2003-04-15. Where does 2004-03-15 come from? (which is 13 months ahead) Likewise for the 2nd statement — Preceding unsigned comment added by 77.119.223.171 (talk • contribs) 22:57, 27 April 2022 (UTC)

en dash vs. hyphen Minus sign for western time zones: am I doing it wrong?

I just made an edit (not logged in, whoops!) to change the en dash to a hyphen in this article's infobox, then realized that was probably a minus sign. I'll put it back. KarenJoyce (talk) 20:31, 6 July 2023 (UTC)

Reply to Jc3s5h

Hey Jc3s5h, thanks for being such a dedicated Wikipedian. I see in your last revert you asked for proof of inference. I'll try to infer what inference you're referring to. I assuming you've already checked section 3.2.1 of your copy of ISO 8601. (If not you can check quickly at this link: https://ipfs.io/ipfs/QmQPxkZQbHtc6AzFCb4sbz4hFC6sYgsr1xoyjNUwi4eFRW). So we're not disputing the text of the standard.

If you're unsure whether ISO/IEC 10646 (a.k.a. Unicode) is derived from ISO/IEC 646 or not, you can follow the "Preceded By" links on Wikipedia. Start at Unicode → Preceded By ISO/IEC 8859 → Preceded By ISO/IEC 646. I don't think there's any doubt Unicode's character repertoire is derived from ISO/IEC 646.

I'm guilty of making this mistake in the past myself, so it's understandable.

Let me know if this clears things up for you.

IJMacD (talk) 02:52, 10 October 2023 (UTC)

The number of characters that could be represented in all the national variants of ISO/IEC 646 collectively is vastly smaller than the number that can be represented in Unicode. I don't think a vastly more expansive character set than ISO/IEC 646 is included in the paragraph in question:

All characters used in date and time expressions and representations are part of the ISO/IEC 646 repertoire, except for "hyphen", "minus” an "plus-minus". In an environment where use is made of a character repertoire based on ISO/IEC 646, "hyphen" and "minus" should be both mapped onto "hyphen-minus".

I think a more reasonable reading would be that an environment that uses the US variant of ISO/IEC 646 would be "based on" ISO/IEC 646.

However I didn't have a copy of the latest standard until you posted a link. I notice that the standard itself uses hyphen-minus. Jc3s5h (talk) 03:09, 10 October 2023 (UTC)

I wouldn't take the literal characters used in that PDF as gospel since it's clearly been scanned so would be entirely up to the OCR software to decide how to encode the printed characters.

With that being said, here's some real inference: I guess paragraph 3.2.1 was really trying to say based on US-ASCII but it referred to the closest standard published by the ISO. I think it's very safe to assume that the intention is to understand ISO/IEC 10646 is derived from ISO/IEC 646 (hence the similar numbering).

I don't think a vastly more expansive character set than ISO/IEC 646 is included in the paragraph in question

"based on" doesn't mean it can't include extra characters.— Preceding unsigned comment added by IJMacD (talk • contribs) 03:33, 10 October 2023 (UTC)

I think "based on" might allow for a few extra characters, but I don't think it's reasonable to say that a character set that is so heavily expanded that it can be used for different languages and different areas of technology is "based on" an earlier technology. Jc3s5h (talk) 15:01, 10 October 2023 (UTC)

Personally I think this argument is clutching at straws to avoid admitting the Wikipedia page on ISO 8601 has been wrong for years. I take certain responsibility myself for propagating these errors but am trying to make amends now.

You have already admitted to gatekeeping the article before ever having actually read the current version of the standard. Do you have any concrete evidence that ISO/IEC 10646 is not based on ISO/IEC 646?

IJMacD (talk) 02:29, 11 October 2023 (UTC)

Whatever the exact wording, I take the statement in the standard to mean that when in an environment like ISO/IEC 646 where there are no separate charatcters for hyphen and minus, both should be mapped onto hyphen-minus. Since ISO 8601 does provide all three characters, the passage does not apply. Jc3s5h (talk) 03:48, 11 October 2023 (UTC)