Talk:ISO 8601/Archive 2

Archive 1

Archive 2

Archive 3

Dashes as alternatives to hyphen

Is there any scope for dashes to be used in place of hyphens? —DIV (128.250.204.118 02:55, 9 October 2007 (UTC))

Where would they be used? Ranges are expressed with a slash / — Omegatron 05:04, 9 January 2008 (UTC)

Definition of Duration is incorrect

From the ISO 8601 spec:

2.1.6 duration non-negative quantity attributed to a time interval, the value of which is equal to the difference between the time points of the final instant and the initial instant of the time interval, when the time points are quantitative marks[IEC 60050-111] ISO 8601:2004(E) © ISO 2004 – All rights reserved 3 NOTE 1 In the case of discontinuities in the time scale, such as a leap second or the change from winter time to summer time and back, the computation of the duration requires the subtraction or addition of the change of duration of the discontinuity. NOTE 2 Duration is one of the base quantities in the International System of Quantities (ISQ) on which the International System of Units (SI) is based. The term “time” instead of “duration” is often used in this context. NOTE 3 For the term “duration”, expressions such as “time” or “time interval” are often used. The term “time” is not recommended in this sense and the term “time interval” is deprecated in this sense to avoid confusion with the concept “time interval”. NOTE 4 The SI unit of duration is the second.

2.1.7 nominal duration duration expressed amongst others in years, months, weeks or days NOTE The duration of a calendar year, a calendar month, a calendar week or a calendar day depends on its position in the calendar. Therefore, the exact duration of a nominal duration can only be evaluated if the duration of the calendar years, calendar months, calendar weeks or calendar days used are known. Vyadh 11:34, 10 October 2007 (UTC)

The format YYYYMMDDHHMMSS or 20241225155054

How come there is no mention of this format in the article, the only thing close is 202412251550, without the second? Candle^{of Hope} 17:35, 18 November 2007 (UTC)

Ordinal dates

Are the days in Ordinal Dates counted from the 1st of January, or from the first monday of the ISO year? It might be worthwhile making this clear in the artical. 203.97.41.180 (talk) 00:20, 28 December 2007 (UTC)

January 1 is 001; December 31 is 365 or 366. The term "ISO year" is meaningless; one should write "ISO week-numbering year" or similar. The yyyy in yyyy-mm-dd and yyyy-ddd is as much an ISO year as that in yyyy-Www-d. ISO could have given a new name to 7*(ww-1)+d, but did not. 82.163.24.100 (talk) 22:09, 24 September 2008 (UTC)

DD-MM?

Is there an unambiguous way to say "August 5"? Is 08-05 the standard way? What about something like 08-05T?

See User:Omegatron/Date_formatting#Conflicts.

Also please comment if you see any factual errors in my proposal. — Omegatron 05:08, 9 January 2008 (UTC)

• Not with ISO 8601 without prior agreement. In your case it is best to just write "August 5". The use of "T" is to seperate the date from the time and can safely be replaced with a space in most cases.--James thirteen (talk) 13:48, 26 April 2008 (UTC)

Scope and application of the standard

Draft of Proposed New Section: Start

Scope and application of the standard

The scope of the standard covers representations for dates, time of day, combined date and time of day, and time intervals. Dates can be represented in three forms: 1) year-month-day of month, 2) year-week number-day of week, and 3) year-day of year. Time of day is represented by using the 24-hour clock. Combined date and time is represented by merging both the date and time of day representations into a single time point. Time intervals are represented in a number of ways by using a combination of a start point, end point, duration, and context information.

The application of the standard is intended to be very broad. It applies to all written communications that contain dates, times, and time intervals regardless of the communication medium (printed, electronic, or hand written) or the location of the sender and receiver (either within an organization, between organizations, or across international boundaries). The application of the standard was never meant to be limited to dates and times processed and displayed by computers. It applies to all industries and all forms of human activity where accurate and unambiguous representations of dates, times, and time intervals are needed for international or domestic communication.

The standard does not cover worded dates, nor does it preclude the use of worded dates. Worded dates are specifically omitted from the standard mostly because their language dependency can impede international communication.

End of Draft

I am proposing to add the above section after “History of the standard” but before “General principles” which I believe will clarify to the online reading public both scope and applicability of the standard. This new section is also intended to clear up any misconception that the standard was developed solely for computer applications and data prcessing.

I am planning to add this section by 2008-02-22 unless there is considerable opposition or major revisions are needed. Regards,--Richardrw 2008-02-01 20:24+04

It has a fundamental error of omission, which will be offensive to many. ISO 8601 section 1 sentence 1 prudently includes the word "Gregorian". I'll add it. 82.163.24.100 (talk) 19:43, 26 September 2008 (UTC)

Ok, I missed your comment before I deleted your inclusion—sorry. Regards,--Richardrw 2008-09-30 20:54+04

I would change: "all forms of human activity where accurate and unambiguous representations of dates, times, and time intervals are needed for international or domestic communication." to exclude religious uses which it is not meant for. Zginder ^{(talk) (Contrib)} 19:12, 20 February 2008 (UTC)

Can you be more explicit on why this needs to be an exception? I have no idea why there should be one. Of course there are lunar calendars and alternative year counts, but that does not make unambiguous communication less valuable. I fully support the addition as proposed. −Woodstone (talk) 20:09, 20 February 2008 (UTC)

It says in the standard when they were choosing what day to begin the week on they thought about business not religion. Zginder ^{(talk) (Contrib)} 22:30, 20 February 2008 (UTC)

On page 26 of ISO 8601-2004(E) it reads "The uniform numbering of weeks necessitates a unique designation of the day on which a week begins. For commercial purposes, i.e. accounting, planning and similar purposes for which a week number might be used, Monday has been found the most appropriate as the first day of the week." Zginder ^{(talk) (Contrib)} 22:35, 20 February 2008 (UTC)

That applies to only one of the date forms in the standard. And that one is rarely used outside of business context. The standard does not prescribe to use that format. Only if week numbers are used, it prescribes that numbering. Do religions have a week numbering system? −Woodstone (talk) 08:18, 21 February 2008 (UTC)

I believe the intent of the standard was to be as inclusive as possible. Of course, the explicit limitation of the standard is its use of the Gregorian Calendar (which was named after Pope Gregory XIII by the way) as the standard’s time scale. For the religions that use other calendars, like the lunar-based calendars used by Islam and Judaism for instance, the standard does not apply. But when their holidays and events are converted to Gregorian calendar dates for the benefit of their worshippers and others, I see no reason why the standard should be excluded.

I plan on revising the sentence under discussion in the final draft to read, “It applies to all industries and all forms of human activity where accurate and unambiguous representations of dates, times, and time intervals are needed when communicating internationally, domestically, locally, internally or even privately—at all levels.” This revision is meant to reinforce the fact that the application of the standard is not limited to international communication, interorganizational communication, or communication within any geographical boundary, but communication done at all levels from an international financial transaction to a private diary entry.--Richardrw 2008-02-21 20:49+04

Amen. ;) −Woodstone (talk) 18:27, 21 February 2008 (UTC)

Time Zone

The Wikipedia Time Zone article[1] and various dictionaries define Time Zone as fixed by geography and not affected by season. For example, New York is in the Eastern US Zone, UTC-5, all year round, even though its offset from UTC changes between EST and EDT.

Granted, ISO 8601 mis-uses Time Zone to refer to the offset from UTC at the time in question.

The Article should be changed so that it describes the difference from UTC in another fashion, though it should include a mention of what ISO 8601 means by Time Zone.

82.163.24.100 (talk) 20:59, 12 July 2008 (UTC)

It's the other way. The time in New York changes seasonally from UTC-5 to UTC-4 and back. So the term UTC-5 is a misnomer for the time zone. The definition of UTC is absolutely clear and in no way changes by season. −Woodstone (talk) 21:15, 12 July 2008 (UTC)

I think you did not correctly parse what I wrote - "... offset from UTC changes ...". Time Zone corresponds to Winter Time, and "Maine's time zone is five hours behind UTC" is valid all year round. 82.163.24.100 (talk) 22:16, 24 September 2008 (UTC)

Minor Edit

Months expressed in words are not allowed by the standard.

The preceding has been changed to the following to conform with the earlier statement that words are not included in the standard. To the best of my knowledge, there is no prohibition for the use of words even though there is no support for words.

Months expressed in words is not included in the standard.

James thirteen (talk) 02:15, 13 July 2008 (UTC)

Perhaps it would be more accurate to state:

• Dates adhering to the standard never contain months expressed in words.

−Woodstone (talk) 07:26, 13 July 2008 (UTC)

Chronological Julian Day Numbers

As far as I can tell, Chronological Julian Day Numbers were devised by Peter Meyer, author of the web site http://www.hermetic.ch. Does this system really have enough general recognition to be mentioned in this article? --Gerry Ashton (talk) 22:37, 13 September 2008 (UTC)

see http://en.wikipedia.org/wiki/Template:JULIANDAY --JimWae (talk) 00:50, 14 September 2008 (UTC)

Please note that Chronological Julian Day Numbers (CJDN) are different from the normal Julian Day Numbers used by astronomers (JD); the JD is always reckoned from Greenwich noon, while the CJDN is reckoned from local midnight. --Gerry Ashton (talk) 01:22, 14 September 2008 (UTC)

I think you make a good point. I added the CJDN to the article in an attempt to link the reference date of 1875-05-20 with the Julian calendar. If there is conversion to the JD or MJD, this may be more appropriate. Otherwise, I would be in favor of deleting the entire paragraph. I believe the whole reference to the Convention du Mètre is insignificant. I cannot understand why the committee chose that as reference point for the calendar. May be someone else cannot explain it. I am also of the opinion that reference point of the calendar should be linked to some astronomical event so in the future if mankind somehow looses track of time we can re-establish the Gregorian calendar. --Richardrw 2008-09-20 22:43+04

I've revised the article to remove the mention of CJDN. Richardrw, none of the varieties of Julian Day Numbers have anything to do with the Julian calendar, except that the epoch of the system is usually described in terms of the proleptic Julian calendar. JDNs can be converted to and from whatever calendar one wishes, with no need to use the Julian calendar as an intermediate step.

I suspect the sigining of the Convention du Mètre was chosen as a non-religious date, and to go through the formality of linking the calendar to a real-world event. In the case of an "interruption of civilization" as some calendar articles have described it, I'm there will be many ways to link the Gregorian calendar to astronomical events even if the text of ISO 8601 does not survive; I suspect the creators of the standard were just going through the motions. --Gerry Ashton (talk) 19:05, 20 September 2008 (UTC)

CJD and CJDN are appropriate terms for numbering ordinary days, which start before New Zealand, move round the globe, and vanish somewhere past Fiji. Likewise MJD and MJDN. If the concept needs to be used in the article, those are appropriate terms to use, though they should not be presumed to be known already. 82.163.24.100 (talk) 22:33, 24 September 2008 (UTC)

The Solar Eclipse of August 1999 would be a suitable reference date; it was visible (total/partial) at Greenwich and at BIPM. It was probably visible from many more national observatories than the average eclipse is. Solar Eclipses are one of the rather few types of astronomical event that are visible only on a single Gregorian date (being brief and invisible at midnight) . 82.163.24.100 (talk) 22:33, 24 September 2008 (UTC)

Missing prescriptions

"For <start>/<end> expressions..."

It should be specified that those elements that may be omitted from the <end> expression are not just any random selection, but the higher order ones. I.e. "YYYY" or "YYYYMM" can be left out and only "MMDD" or "DD" supplied. But supplying "YYYYDD" or "MM" is not permitted.

--Stig.larsen (talk) 18:01, 14 May 2009 (UTC)

Scope and application of the standard (2)

This section: Scope and application of the standard, appears to be wholly at odds with what the ISO actually says their 8601 standard is about (citation: ISO, FAQ: Numeric representation of Dates and Time). I’ll give the I.P. editor who put that section in a few days to properly cite the wild-looking allegations. If they are not fully cited by authoritative sources, the material has to go. Greg L (talk) 05:01, 14 September 2009 (UTC)

• It’s been two weeks and the highly dubious content in Scope and application of the standard is still not cited. I have removed it. We’ve got a single-purpose I.P. editor, which is a Verizon account tracing to Herndon Virginia, who has been putting un-cited fantasy imaginations in this article. ISO themselves does not say that their standard “applies to all written communications … [even] hand written … when communicating internationally, nationally, locally, internally, or even privately.” If this I.P. editor—or even some sock from another I.P. address—puts the material back in without full and proper and verifiable citations, he or she may well be blocked. Moreover, I will see if I can get a WP:CheckUser done since I’ve encountered this Herndon Virginia I.P. city before and suspect the individual behind it all is a registered editor who logs out to engage in prohibited activity. Greg L (talk) 16:58, 19 September 2009 (UTC)

Herndon VA is the home of Verizon - all their IP's are registered there. Rich Farmbrough, 17:28, 17 November 2009 (UTC).

Brackets

I rather think the use of [] in the article is not as per the standard. Regardless the [] are not part of the standard just a usage in the standard. Rich Farmbrough, 17:28, 17 November 2009 (UTC).

Truncated representations

Current revision of this article says:

ISO 8601:2000 allowed truncation (by agreement), where leading components of a date or time are omitted. Notably, this allowed two-digit years to be used and the ambiguous formats YY-MM-DD and YYMMDD. This provision was removed in ISO 8601:2004.

whereas section section 4.1.2.2 of the version of the standard given as a reference says

When the application identifies the need for a complete representation of a calendar date, it shall be one of the numeric expressions as follows, where [YYYY] represents a calendar year, [MM] the ordinal number of a calendar month within the calendar year, and [DD] the ordinal number of a calendar day within the calendar month.

Basic format: YYYYMMDD Example: 19850412

Extended format: YYYY-MM-DD Example: 1985-04-12

Am I misunderstanding something, or have ISO made a mistake?--Wikipedia of being authoritative ;-) -- Phil Barker 09:23, 18 November 2009 (UTC)

I believe the 2004 standard section 4.1 is dividing the treatment of dates in the year range 0 through 9999 into two subsections, 4.1.2.2 for complete dates, that name a specific day, and 4.1.2.3, which covers reduced accuracy dates (that is, a century, a year, or a month. Nowhere does it say the leading digits of the year may be omitted. Jc3s5h (talk) 17:18, 18 November 2009 (UTC)

Sorry, I had completely missed the point of what truncated representations were about. Thanks for the clarification.-- Phil Barker 17:39, 20 November 2009 (UTC)

Archiving

Does anyone object to me setting up automatic archiving for this page using MizaBot? Unless otherwise agreed, I would set it to archive threads that have been inactive for 60 days. Jc3s5h (talk) 23:48, 9 December 2009 (UTC)

Since the both the article and this page are concerned with time spans that are significantly larger than 60 days and this page is significantly shorter than the article, I see no reason to archive. I admit that I have grown to dislike automatic archiving as the procedure often makes it appear that a problem has gone away rather than ignored. JimCubb (talk) 03:45, 13 December 2009 (UTC)

I already set up archiving. If I had not, the talk page would have been about 96 kilobytes, compared to an article size of 26 kilobytes. I do tend to agree that putting things in the archive does tend to lead to issues being revisited unnecessarily. It's to bad there isn't a system that provides a table of contents of the archive that is visible on the talk page. --Jc3s5h (talk) 04:04, 13 December 2009 (UTC)

Applying ISO 8601 in the Arab World

i'd like to learn the right way to do so. By not having that particular translation, we are missing a huge Sprachraum that composes one of the six official UN languages. Can someone help with this? Warmest Regards, :)—_thecurran Speak your mind ^{my past} 16:57, 11 January 2010 (UTC)

How to express the dates from 2010-04-12 to 2010-04-16 according to ISO8601?

It is often necessary to express several consecutive days in dates, for instance, April 12-16, 2010. What is the right way to express these dates according to ISO8601? --Roland 10:57, 29 January 2010 (UTC)

The standard prescribes a solidus (/) as separator of start and end date, where the intial equal part may be omitted, so it would read: 2010-04-12/2010-04-16 in full, or 2010-04-12/16 shortened. Alternatively one could use 2010-04-12/P5D, using a period of 5 days. −Woodstone (talk) 11:57, 29 January 2010 (UTC)

See ISO_8601#Time_intervals. Mitch Ames (talk) 12:01, 29 January 2010 (UTC)

External link Citaton to site requiring registration

The link to 'Technical Committee ISO/TC 154, Processes, data elements and documents in commerce, industry and administration.' requires registration, shall it therefor be removed? Reboot81 (talk) —Preceding undated comment added 08:28, 11 October 2010 (UTC).

No. See WP:PAYWALL. Just because it requires registration does not violate WP:Verifiability. —sroc (talk) 11:45, 11 October 2010 (UTC)

We distinguish between citations, which support material in the article, and external links, which refer to related material that is not covered in the article (or which was not used while writing the article). Sites which require registration or payment are acceptable as citations, for the same reasons that paper books are allowed as citations. Jc3s5h (talk) 12:02, 11 October 2010 (UTC)

Sorry, I was getting mixed up between:

• Footnote 3: TC 154 Processes, data elements and documents in commerce, industry and administration
• External link: Technical Committee ISO/TC 154, Processes, data elements and documents in commerce, industry and administration

Yes, the external link should be either deleted or incorporated as a citation if needed to support any claims in the article. —sroc (talk) 12:13, 11 October 2010 (UTC)

Current Time box

This box initially confused me, as it does not match the current time at my location (UK), even allowing for daylight savings. Is it using the current time at the server location instead? —Preceding unsigned comment added by 144.32.48.132 (talk) 10:09, 11 October 2010 (UTC)

Wikipedia does computations to change pages from wiki markup (what you see when you click the edit tab) to HTML (which can be displayed by your browser). To save computer time, instead of redoing the computation every time someone looks at the page, copies of the HTML are cached and reused. That is why the time shown on the page is likely to be earlier than the time you viewed it. Jc3s5h (talk) 10:33, 11 October 2010 (UTC)

Dates Section

The Standard not only uses the (secular) Gregorian Calendar, it defines it. That should be mentioned, I think.

Actually, except for regions under Papal RULE in 1582, and for the British Empire and Colonies as at 1752, I don't know what the formal legal authority might be for using the Gregorian Calendar in all the different jurisdictions. Can an ISO standard provide authority of itself, as opposed to being specified by legislation?

82.163.24.100 (talk) 21:42, 11 October 2010 (UTC)

Normally a standard cannot provide legal authority unless it is adopted by a government. However, in the absence of any relevant definitions in legislation, words have their ordinary meaning. If a standard is so influential that the definitions in the standard become an integral part of the language, and those words are used in legislation, the standard would influence the legal meaning of words. I don't think ISO 8601 has had that degree of influence. Jc3s5h (talk) 22:10, 11 October 2010 (UTC)

ISO 8601 "defines" the Gregorian calendar in clause 2.2.15 under 2 Terms and definitions, and describes it in clause 3.2.1, but only so that the standard itself can use the term Gregorian calendar unambiguously. The Gregorian calendar itself was well-defined before ISO 8601 came along. 8601 also "defines" terms such as year, month etc with the same level of authority - ie none. It is common for all ISO standards to define the use and meaning of specific terms within the scope of that standard to ensure that there is no ambiguity.

Note that although standards define terms for use within the scope of that standard, it is quite reasonable for an external entity to specify the use of those same definitions for purposes outside of the standard (although generally on a related mattter). For example, if one wanted to unambiguously specify a particular method of cryptographic padding, one might specify "ISO/IEC 9797-1:1999 Padding Method 2" - even if the padding was not for a MAC (which is what 9797-1 covers. (Not at all related to ISO 8601, and perhaps not the best example, I know - but one I happen to be familiar with.) Mitch Ames (talk) 12:48, 12 October 2010 (UTC)

Ranges Section

Time ranges like "2007-11-13/15" need more spec for me. Is this a two day or three day interval--I'm forced to look elsewhere for a spec. "For <start>/<end> expressions, if any elements are missing from the end value, they are assumed to be the same as for the start value including the time zone." This implies it is a two-day interval. http://www.ukoln.ac.uk/metadata/dcmi/date-dccd-odrf/ implies that the range is not precise (+/- one day). —Preceding unsigned comment added by 128.255.33.125 (talk) 21:32, 30 November 2010 (UTC)

I've updated the text to clarify it. Mitch Ames (talk) 11:18, 1 December 2010 (UTC)

Any provision for trimesters ?

1st-4th quarter ? --Jerome Potts (talk) 12:39, 20 December 2010 (UTC)

No. Mitch Ames (talk) 13:31, 21 December 2010 (UTC)

To a certain extent yes. General time intervals are supported. The first quarter is denoted 2010-01/03; the first trimester is 2010-01/04.−Woodstone (talk) 16:19, 21 December 2010 (UTC)

Thanks. Odd, that 01/04 notation, and the differenciation between a quarter and a trimester. Why is that ? --Jerome Potts (talk) 20:21, 24 December 2010 (UTC)

I think Woodstone is incorrect in saying that the "first trimester is 2010-01/04". According to the Shorter Oxford English Dictionary, a trimester is "a period or term of three months" (with instances of usage being in pregnancy and university or school term), ie it is the same length as a quarter (three months) - although the two terms are used in different contexts. 8601 does not define or use the terms trimester or quarter. Even 2010-01/03 doesn't necessarily mean a quarter - it defines a range from some time in January to some time in March. So it could be as few as 29 days (from 2010-01-31 to 2020-03-01), plus or minus a just under a day depending on the time of day at each end. Likewise 2010-01/04 includes a range from just over two months (2010-01-31/04-01) to just under four months (2010-01-01/04-30). If you actually wanted to specify 1st quarter of 2010, you'd have to write 2010-01-01/03-31. If you wanted to specify a duration of three months - without a specific start date - it would be P3M (P=period/duration 3 Months). Mitch Ames (talk) 08:11, 27 December 2010 (UTC)

Bug in current date/time box?

Hi,

today (2011-01-01) the box with the current date/time shows: "Date with week number: 2011-W52-6" I think it should be "2010-W52-6". What's correct? 93.104.98.13 (talk) 12:04, 1 January 2011 (UTC)

Fixed. It should be "2010-W52-6", see ISO week date. I also fixed the ordinal date, as that (wrongly) used the ISO year. See Help:Wiki markup#Variables and mw:Help:Extension:ParserFunctions#.23time for further reference.--Oneiros (talk) 12:38, 1 January 2011 (UTC)

Precision vs accuracy

In "General principles", someone recently changed the word "accuracy" to "precision", but I've reverted it, and also reworded the last bullet point to remove the word "precision". As an engineer I appreciate the difference between accuracy and precision, but the standard itself uses the word "accuracy" and not "precision". Quoting some of the relevant clauses from ISO 8601:2004(E):

2 Terms and definitions:

2.3.3 basic format ... format of a date and time representation or date and time format representation comprising the minimum number of time elements necessary for the accuracy required

2.3.7 representation with reduced accuracy ... abbreviation of a representation by omission of lower order components

3 Fundamental principles

3.1 Basic rules ... Both accurate and approximate representations can be identified ...

4 Date and time representations

4.1.2.3 Representations with reduced accuracy

4.2.2.4 Representations with decimal fraction ... If necessary for a particular application a decimal fraction of hour, minute or second may be included.

I'm not sure that "precision" as defined in our Accuracy and precision article is necessarily better in the context of 8601, but in any case I think it is important that our 8601 article use the same word as the standard. Mitch Ames (talk) 02:39, 8 January 2011 (UTC)

Interestingly, the word "precision" is not used in the 2004 edition with "accuracy" always used, but the word "accuracy" is not used in the 2000 edition "precision" is used instead. As the 2004 is the current edition, I believe, we should use "accuracy". Zginder 2011-01-09T02:16Z (UTC)

Where/When are people supposed to use the ISO 8601?

It is 23 years since the ISO 8601 was first published in 1988, but I have not quite seen people use it. Europe still uses 07/02/2011 and North America still uses 02/07/2011 for February 07, 2011. Where/When are people supposed to use it? I myself use it in my computer, which makes the management of files much easier, but I have not quite seen other people using it. --Roland 11:13, 7 February 2011 (UTC)

Like all ISO standards, it is voluntary, unless your government passes a law making one of the standards mandatory. So use it if you feel like it. Jc3s5h (talk) 17:46, 7 February 2011 (UTC)

I do hope that people all over the world use it so that unnecessary confusion can be avoided when they communicate with each other. --Roland 04:30, 10 February 2011 (UTC)

I hope people will not use it, because the price ISO charges to obtain it is too expensive for most people, and people who don't read it are likely to unknowingly violate it. In particular, anyone who writes about western history will probably use the Julian calendar at times, and this is not allowed under ISO 8601. Jc3s5h (talk) 13:47, 10 February 2011 (UTC)

If people the world over did no more than use the basic YYYY-MM-DD and (24-hour) hh:mm:ss - which is stated for free here - for normal non-historical use, there would be a bit less confusion. Mitch Ames (talk) 2011-02-11T20:41Z

I use it whenever a written date is required. A personal check, form, or other document that wants me to put a date (in an ambiguous format) is written as YYYY-MM-DD format. I would encourage others to do the same. That's a good way to promote its usage; by using it in everyday documents. — Preceding unsigned comment added by 24.130.34.7 (talk) 02:54, 25 May 2011 (UTC)

I use it in file names where I want to keep several versions edited on different days. Alphabetically sorted file list will then be chronological too. - But here in wikipedia, such testimonials and opinions carry little weight; it would be nice to have a citable source say something about actual usage!--Nø (talk) 08:45, 25 May 2011 (UTC)

Calendar dates

"The standard also allows for calendar dates to be written with reduced precision. For example, one may write "1981-04" to mean "1981 April", and one may simply write "1981" to refer to that year or "19" to refer to that century."

I'm confused: does the ISO standard specify that "19" refers to the 20th century or did the writer assume so? Regardless, it's worht clarifying - as anyone will now, 1981 is in the 20th century and using "19" to represent "20" is odd, at least.

Just my 2¢. — Preceding unsigned comment added by 188.82.143.212 (talk) 15:59, 21 August 2011 (UTC)

The ISO date 19 means all years who's first two digits are 19. So, it is 1900 through 1999. Some people would describe this as the 20th century, others would say the 20th century is 1901 through 2000. But any 100 year period is a century, so 1900 through 1999 is certainly a century. Jc3s5h (talk) 16:24, 21 August 2011 (UTC)

I've updated the article to clarify it. Mitch Ames (talk) 13:08, 22 August 2011 (UTC)

Adding a time zone to a date

Which of the following, if any, is the correct way to specify today's date without a time but with a UTC time zone indication?

• 2011-09-01Z
• 2011-09-01TZ

Or can a time zone only be used when you specify at least the hour of the day? --Oz1cz (talk) 14:19, 1 September 2011 (UTC)

I have an electronic copy, which I think is some kind of draft. I gather the final version is the same except for page and section numbers. It states, with respect to reduced accuracy date and time representations:

the date component shall not be represented with reduced accuracy;

The least precise example given is:

1985-102T10:15Z

Since the least accurate time representation described in the standard is the hour, I think if you want to designate UTC you must give at least the hour, not just the date. Jc3s5h (talk) 14:48, 1 September 2011 (UTC)

According to ISO 8601:2004(E):

4.2.5.1 Difference between local time and UTC of day
... Expressions of the difference between local time and UTC of day are a component in the representations defined in 4.2.5.2; they shall not be used as self-standing expressions.
4.2.5.2 Local time and the difference from UTC
When it is required to indicate local time and the difference between the time scale of local time and UTC, the representation of the difference shall be appended to the representation of the local time following immediately, without space, the lowest order (extreme right-hand) time element of the local time expression.

It seems clear that you can only use a time zone designator with a time of day, not a date. Mitch Ames (talk) 11:56, 2 September 2011 (UTC)

Thank you, both of you. It was as I feared. I wonder why the standard doesn't consider this issue.--Oz1cz (talk) 14:47, 3 September 2011 (UTC)

Why is it an issue? If you're specifying a date, that's a range of 24 hours, so the time zone is most likely not relevant. If the time zone matters, then perhaps a time component (at least an hour) is required - and then you can append the time zone.

Actually I can think of a scenario where this might be an issue: the date of death of someone at sea. See Talk:John_Forrest#Date of death for details. Mitch Ames (talk) 01:47, 4 September 2011 (UTC)

It is rarely an issue, but there are situations where it matters. For example, when dating the attack on Pearl Harbor, an American and a Japanese text may use different dates: 1941-12-07 in Hawaii, 1941-12-08 in Japan.--Oz1cz (talk) 12:17, 4 September 2011 (UTC)

Precision vs accuracy (2011-09)

I have again reverted the word precision back to accuracy. As per a previous discussion the standard itself uses the word accuracy (in several places), and unless there is a compelling reason otherwise, I believe we should use the same term in our article. Mitch Ames (talk) 09:35, 11 September 2011 (UTC)

I've added a note to the article, stating that that standard uses the word accuracy. This may go some way to justifying the use of the word in the article.

Actually there are several other places in the article that use the word precision. I thought about changing those as well, but I don't think it would read so well if I did. Perhaps we should use precision everywhere, but state explicitly that the standard uses accuracy. Thoughts, anyone? Mitch Ames (talk) 09:58, 11 September 2011 (UTC)

"Potential for ambiguity" - original research?

I've moved some text ("The basic format can appear to be ambiguous to those unfamiliar with the standard") out of General principles and into a new section Potential for ambiguity, and added a couple more examples. I think it is useful information, and describes a real-world problem. However I'm a little concerned that this might constitute original research, because the standard itself doesn't mention any of these problems. Does anyone know of any references that might support this section? And/or do other editors consider it OR, and if so, what else, if anything, can we do about it? Mitch Ames (talk) 12:09, 5 December 2011 (UTC)

I think the section only makes statements that are obvious to people who are reasonably familiar with writing dates. Of course, verifiable spectacular examples of misinterpretations leading to dire results would make the section more exciting. Jc3s5h (talk) 18:45, 5 December 2011 (UTC)

what about the kk:mm:ss

I have seen the kk:mm:ss format being used in various places. I cannot seem to find anything on Wikipedia on this format. Does anyone have some information about this format ? — Preceding unsigned comment added by 142.164.179.47 (talk) 15:53, 17 February 2012 (UTC)

What does the k stand for? Jc3s5h (talk) 16:11, 17 February 2012 (UTC)

ISO 8601:2004 does not use "kk:mm:ss", which is why it is not mentioned in this article. It appears that "kk" may indicate hours in the range 01-24, in Java (programming language)'s SimpleDateFormat class. Such level of detail in a specific context (Java) is probably beyond the scope of most Wikipedia articles. Mitch Ames (talk) 05:35, 18 February 2012 (UTC)

Double hyphen

Does someone have a reference for this change, ie from "--" to "＝" (double hyphen)?

The standard just says "In certain application areas a double hyphen is used as a separator instead of a solidus", without defining "double hyphen". The double hyphen article has no references at all, so that's not much help. Mitch Ames (talk) 14:30, 6 June 2012 (UTC)

A Google search for ISO 8601 double hyphen finds several pages, including [2][3][4][5][6], which describe the "double hyphen" as "--", but none that I could see mention "＝". 203.176.108.99 (talk) 23:45, 6 June 2012 (UTC)

Given an least one reputable source saying "--" and none saying "=", I've reverted the article to "--", also noting that the standard itself does not define the term "double hyphen". Also, clause 3.4.1 says:

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

Given that double hyphen/＝ is not in ISO/IEC 646 and 8601 does not mention how to map "double hyphen" to a 646 character (as it does for hyphen and minus), it seems unlikely that "double hyphen" is the non-646 character. Mitch Ames (talk) 07:05, 9 June 2012 (UTC)

Bad example

The example in the top-right box should depict a date where the day-of-the-month is above 12, making the example self evident.201.53.141.60 (talk) 13:54, 5 July 2012 (UTC)

The example displays the current date, rather than being a specific example of non-ambiguity. Mitch Ames (talk) 09:12, 7 July 2012 (UTC)

Including seconds in examples

None of the examples appear to indicate that including a time of seconds is inherently supported. Usually the second is the default increment of time for most computer-based applications; I would think a time involving seconds should be included as most of the examples (e.g., "2012-07-23T14:30:53-0400"). Most of the examples including a date and time have only minute-resolution. Jcronen1 (talk) 17:07, 23 July 2012 (UTC)

Several of the examples include seconds. Search the article for "13:47:30", "14:45:15Z", "2007-03-01T13:00:00Z/2008-05-11T15:30:00Z". Mitch Ames (talk) 13:08, 24 July 2012 (UTC)

Box example

Is the box example based on the user's current time when it computed the "current at page generation"? If it is, then it seems to be off by a lot.

So, as of "Date and time (current at page generation)", the UTC is: 2012-10-14T21:57Z My current time when I first visited it on this computer and browser and IP address I'm using now is: 2012-10-15T18:52+08:00

We do not use DST. If I understood "current at page generation" correctly, being based on the first visit of the user, then the example should have shown: 2012-10-15T10:52Z not 2012-10-14T21:57Z.

Thank you for the clarification.

--- Laibcoms (talk | Contribs) 11:08, 15 October 2012 (UTC)

If I understand how MediaWiki works correctly, "current at page generation" would mean the time when the page was first viewed after either the last time it was edited or the last time the cache was purged, whichever is most recent. Cache purges can be requested by users, or (I believe) happen automatically when templates are edited. They may also happen periodically automatically, although I'm not sure about this. I don't believe it is related at all to any particular user's visits to the page. JulesH (talk) 11:29, 28 March 2013 (UTC)

XKCD comic

I find the comic useful. I think many people seeking to understand ISO 8601 or looking for resources to explain it to others would benefit greatly from having the comic linked here. I restored it because it was removed by an anonymous user with no discussion. Bayonetblaha (talk) 15:56, 27 February 2013 (UTC)

Funny, yes; useful, no. Definitely not appropriate. Specifically:

• it is not "informative" (it doesn't tell us anything that's not already in the article - WP:ELNO item 1),
• it is not "factual" (who actually discourages the formats "10/11011/1101", "2013.II.27" etc? ELNO - item 2),
• it is self-published personal site (ELNO item 11)

If you really want a resource to explain it, ISO's page http://web.archive.org/web/20110614235056/http://www.iso.org/iso/support/faqs/faqs_widely_used_standards/widely_used_standards_other/date_and_time_format.htm does (did?) a far better job. Sadly it's not currently on their website, hence the archived link. I e-mailed ISO back in 2012-11 about it, and was told "We are currently working on a new version of this page, so for the moment it's not available. I will get back to you as soon as it's ready." - but I haven't heard back yet. Mitch Ames (talk) 13:57, 28 February 2013 (UTC)

What do you mean, "no discussion"? WP:EL has been discussed. There's a consensus not to put every funny picture referencing stuff to Wikipedia articles. Just think what the article on cats would be like if everyone was pushing their funny pictures like this. Furthermore, the reasons for including the comic are dubious at best: User:DFrier who first included it stated in their edit comment that "(...) It encourages a wider public to use the standard 3) If you must be a humorless git, don't be anon" which seems to me [s]he thinks Wikipedia is a place to promote certain standards or a jokebook. 128.214.136.233 (talk) 14:03, 28 February 2013 (UTC)

Double hyphen

Article currently states:

The standard does not define the term "double hyphen", but previous versions used notations like "2000--2002".[14]

This reads as unsourced OR criticism of the standard. Link 14 does not criticise in the same way, even if it substantially verifies the factual content of the statement. FWIW, "hyphen" is a well-defined term, defined in both the ISO/IEC 8859 family of specifications and in ISO/IEC 10646 as code point 29h, and "double" is a common English term which is in this context unambiguous, so to suggest that "double hyphen" could mean anything other than the literal string "--" seems faintly ridiculous. JulesH (talk) 11:22, 28 March 2013 (UTC)

It's not intended to be criticism - it is a simple, neutral statement of fact, verifiable by checking the standard itself. While "hyphen" is well defined, we have an article on double hyphen that states that it is not --, but rather ＝. Ie the term "double hyphen" does appear to be ambiguous (in that we have multiple different interpretations of it), hence I believe it worth noting that the standard doesn't define it. Any suggestions as to how we might better word it? (The current wording is certainly more neutral than [7]'s "somewhat vague note". Mitch Ames (talk) 14:23, 29 March 2013 (UTC)

The note about exceeding carry-over points partly false

«The standard does not prohibit date and time values in a duration representation from exceeding their "carry-over points" except as noted below.» — That's not entirely true as according to the the 2004 standard that seems to apply only to the alternative format (4.4.3.3). The whole reason of having separate units is because some are nominal and some accurate — 48 hours is not necessarily 2 days. Andri Möll (talk) 12:05, 16 April 2013 (UTC)

I've just checked 8601:2004 and as far as I can see, the statement that "The standard does not prohibit date and time values in a duration representation from exceeding their 'carry-over points' except as noted below." is correct. ("As below" referring to the next paragraph, to which I've just added an inline ref to clause 4.4.3.3)

However if that statement is wrong, and the standard does prohibit values from exceeding their carry-over points anywhere other than in 4.4.3.3, it should be easy to determine. Can you quote the relevant text (citing clause number(s)) from the standard that prohibits it? Mitch Ames (talk) 13:32, 16 April 2013 (UTC)

Umm, first of all, am I interpreting this correctly? The "except as noted below" phrase would almost hint that an exception is made for the alternate format of durations, while I'm arguing that the that that's the only place where units must not exceed the carry over points.

Which relevant text are you referring to? I'm looking at the 4.4.3 Duration section and carry over points are only mentioned in 4.4.3.3 which talks about a format resembling a regular date/time format, not the format with designators (P*) in 4.4.3.2.

Section 2.1.7 also states the definition of nominal durations, which years, months and days are, and their accurate duration can only be evaluated if you know their position in a calendar. Given that a duration (as opposed to an interval) has no date/time, it's impossible to translate between months, days and time units. Andri Möll (talk) 14:01, 16 April 2013 (UTC)

"... am I interpreting this correctly?" — The article says (with my italics here for emphasis):

The standard does not prohibit date and time values in a duration representation from exceeding their "carry-over points" except as noted below ...

Alternatively, a format for duration based on combined date and time representations ... PYYYYMMDDThhmmss ... individual date and time values cannot exceed their moduli ... ^{[clause 4.4.3.3 Alternative format]}

which is logically equivalent to

The only place the standard prohibits values exceeding their carry over points is clause 4.4.3.3, which defines an alternative format that combines date and time elements, separated by "T", but doesn't have other designators (eg Y, M, D, H, M, S).

So far as I can tell both statements are correct.

"Which relevant text are you referring to?" — I was asking you to quote any text from the standard (other than the already noted 4.4.3.3) that does prohibit values exceeding "carry over". Quoting such text - if it existed - would be the simplest way of refuting the sentence "The standard does not prohibit ..."
(I believe that the article is correct, and that no such text actually exists - but of course I could be wrong.)

"Section 2.1.7 also states the definition of nominal durations ... and their accurate duration can only be evaluated if you know their position in a calendar. Given that a duration (as opposed to an interval) has no date/time, ... — This is true but irrelevant. The issue is whether I can specify (for example) a duration of 13 months (P13M) instead of 1 year and 1 month (P1Y1M), both of which are nominal, rather than exact, durations; or 75 minutes (PT75M) instead of 1 hour and 15 minutes (PT1H15M), both of which are exact.

Mitch Ames (talk) 06:30, 21 April 2013 (UTC)

Combined date-time

"A single point in time can be represented by concatenating: a complete date expression, the letter T as a delimiter, and a valid time expression. For example '2007-04-05T14:30'.

Either basic or extended formats may be used, but both date and time must use the same format."

This could use some clarification. The first sentence of the first quoted paragraph implies that "2007-04-05T14" would be valid (N.B. "14" is a valid time expression!). That is not the case, due to some ramifications of the quoted sentence from the second paragraph, viz. "T14" is considered basic format. Note also that "14.0" (i.e. with fractional hours) as a time specification is also considered basic format.

The only valid way to construct a date-time string with time resolution limited to hours is to use basic format for the date portion, e.g. "20070405T14".

Note also that zone specification (UTC or offset from UTC) is considered part of the time, and can only be included if some time element (hours at minimum) is included. Therefore it is not possible to specify date-time limited to precision of a day while specifying a specific time zone. That is an inconvenient limitation of ISO 8601 format, as it is sometimes desirable to specify a date with a particular zone (e.g. for product release dates). — Preceding unsigned comment added by 68.186.246.74 (talk) 20:32, 22 April 2013 (UTC)

My reading of 8601:2004 clause 4.3 "Date and time of day" is that the requirement that both date and time be the same format (basic or extended) only applies for reduced accuracy. In particular that requirement is item d under 4.3.3.
Clause 4.3.2 "Complete representations" lists examples of all-basic and all-extended formats, but does not (so far as I can see) mandate that date and time be the same format. Thus it appears that our article is wrong, and probably should be:

(I've add bold here for emphasis - that bold would not be in the article.)

A single point in time can be represented by concatenating a complete date expression, the letter T as a delimiter, and a valid time expression, eg "2007-04-05T14:30". It is permitted to omit the 'T' character by mutual agreement. [ref clause 4.3.3]

The date expression may be calendar, week, or ordinal, and must use a complete representation. The time expression may use reduced accuracy, but if it does, it must be of the same format (basic or extended) as the date expresssion. [ref clause 4.3.3].

Alternatively, can someone point to the specific clause/text that says the same format must be used for both date and time in complete representations. Mitch Ames (talk) 12:00, 24 April 2013 (UTC)

Hmm... The paragraph preceding the NOTE in 4.3.2 discusses separators and states that they "shall be used, in accordance with 4.4.4 [...] when required". 4.4.4 is the heading for complete representations of time intervals. 4.4.4.1 first paragraph refers back to 4.3.2 and states a requirement for basic vs. extended consistency. It is unclear (i.e. ambiguous) whether 4.4.4.1 as a subsection of 4.4.4 applies only to date-time within an interval, or (via the forward reference from 4.3.2) to stand-alone date-time as well. 68.186.246.74 (talk) 03:04, 28 April 2013 (UTC)

Ah, I see your point now.

I don't understand why the paragraph preceding the NOTE in 4.3.2 (which is under 4.3 "Date and time of day", defining one time instant) refers to 4.4.4 (which is under 4.4 "Time interval", being generally two instants). It doesn't make sense. I strongly suspect that it's actually an error, and that the paragraph preceding the NOTE in 4.3.2 should refer to 3.4.4 "Characters used as separators" - which would make a lot more sense. Unfortunately a quick search finds no errata for 8601, so I've nothing to back up my suggestion that it's a typo.

I am inclined to think that the "date and time must be the same format" rule only applies to reduced accuracy (4.3.3) - if it were intended to applied to all representations it would have been specified somewhere other than under "representations other than complete". Mitch Ames (talk) 07:24, 28 April 2013 (UTC)

So the remaining question, as I understand it, appears to be whether or not a complete date-time which is itself not part of an interval or recurrence can incorporate a mixture of basic and extended formats. I think we're agreed that the standard could be clearer on this point that it is.

I suspect that the intent was that the date-time should be either all basic or all extended format:

1. See Annex B.1.3, which gives examples of complete representations of date-time using the three date format variants (calendar, week, ordinal). There are columns for basic format and for extended format, but none for mixed format (which I expect would have been included if that were intended to be allowed).

2. Hierarchy and composition/decomposition: a recurrence representation is 'R' followed by an optional number followed by a solidus followed by an interval. An interval is a lone duration, a duration then solidus then a time point, a time point then solidus then duration, or two time points separated by a solidus. Ignoring duration, which is not relevant to the question at hand, a time point is a date, a time, or a combination. A combined date-time is a date usually followed by 'T' followed by time.

To construct a more complex representation (with a few noted special cases) one can combine simpler ones in a prescribed order with prescribed separators. Likewise, for parsing one can separate a complex representation into a combination of simpler elements.

Completely-specified intervals involving time points clearly require overall consistency [4.4.4.1, 4.4.4.3, 4.4.4.4], and that is unchanged with recurrences

A stand-alone date is either basic format or extended format; there can be no mixture.

A complete local time, likewise, is either basic format or extended format; no mixture. Adding a fraction and/or UTC indication doesn't change that.

Section 4.2.5.2 is interesting; it gives examples of basic and extended formats but no mixtures, yet the text neither explicitly permits nor prohibits mixtures. This appears to be a second example of lack of clarity on the same point.

Given the fact that both more complex (viz. intervals and recurrences) and simpler (i.e. stand-alone date and stand-alone time (modulo the lack of clarity of 4.2.5.2)) require consistency, I would be very much surprised if the intent were to permit an exception to that requirement without a clear statement to that effect. Put another way, if a date-time time point were permitted to be a mixture of basic and extended format, why would that mixed format time point be invalid when combined with a duration in an interval?

3. Additional information:

RFC 3339 Appendix A attempts to construct ABNF for an earlier version of ISO 8601, notes the ambiguity, and decides on permitting a mixture. Its ABNF permits a mixture even in intervals (called "period" in the ABNF).

The W3C profile uses only extended format.

The CCSDS Blue book specification also uses only extended format, and has no provision for offset from UTC.

The Library of Congress draft attempts BNF for their profile ("Level 0") of ISO 8601. Their equivalent of a complete date-time time point uses only an equivalent of extended format, except for the following oddity. Oddly, however, it permits a date-time to be constructed from an incomplete date (e.g. year only) and a time (in contrast to the CCSDS Blue book section 3.5.1.3 paragraph e).

68.186.246.74 (talk) 14:22, 28 April 2013 (UTC)

Usage

The U.S. Library of Congress is apparently working on a related date-time specification which includes a profile of ISO 8601 and some proposed extensions.

URI: http://www.loc.gov/standards/datetime/pre-submission.html

The Consultative Committee for Space Data Systems has a freely available standard which includes text ("ASCII") profiles of ISO 8601 corresponding to extended format calendar and ordinal UTC date-time (which can be reduced ("subset") to date or time). Interestingly, the document contains no copyright notice or restrictions.

Descriptive Blurb from the CCSDS web site:

CCSDS 301.0-B-4

File size: 350,812 Bytes

Time Code Formats. Blue Book. Issue 4. November 2010.

This Recommendation establishes a common framework and provides a common basis for the formats of time code data.The current issue defines a second P-Field octet for the CCSDS Unsegmented Time Code (CUC) and adds a Security Section.

URI: http://www.ccsds.org/documents/301x0b3.pdf

68.186.246.74 (talk) 04:40, 28 April 2013 (UTC)

Ambiguities

"For example, '2004-05' is a valid ISO 8601 date, which indicates May (the fifth month) 2004. This format will never represent the 5th day of an unspecified month in 2004, nor will it represent a time-span extending from 2004 into 2005."

However, "2005-05" can also represent 4 minutes past 8:00 P.M. in a local time which is 5 hours West of UTC (e.g. New York City in U.S. EST time) in basic format. The basic format date could be disambiguated by prefixing with '+' (however, requiring agreement), and the basic format time could be, and probably should be, disambiguated by prefixing with 'T'; however the quoted string remains ambiguous without additional information.

This is an example of why the basic format should be avoided in text except where there is no extended format alternative (the extended format time "20:04-05" is unambiguous).

Likewise "2004" is ambiguous (year only (considered basic format) or local time with unspecified offset (also basic format)). The time can be rendered unambiguously as above, viz. "20:04" or "T2004" or even "T20:04".

Different sorts of ambiguities exist for intervals specified by start and end points, where use is made of the allowance for eliminating "higher order" components and/or zone of the end point (section 4.4.5). The referenced section states that "in such a case it shall be assumed that the corresponding time elements from the 'start of time interval' expression apply". For example, consider "2012-07-31T20:30:40-05:00/50+01:00". It is unclear in the example (with explicitly different zone offsets) precisely how long the specified interval is; i.e whether "the corresponding time elements" refers to equivalent Universal Time values or to the specified numeric values. In "2012-06-30T20:59:50/2012-07-01T04:00:10" (no zone offset specified), the duration is ambiguous because in some zones (but not in others) there was a leap second inserted between the specified local times. This is a documented case (section 2.1.6 NOTE 1) of the fact that some time intervals are imprecise because of varying durations of time elements (years, months, and in this case, days) — Preceding unsigned comment added by 68.186.246.74 (talk) 00:52, 17 April 2013 (UTC)

"An expanded year representation [±YYYYY] must have an agreed-upon number of extra year digits beyond the four-digit minimum, and it should always be prefixed with a + or − sign instead of the common AD/CE or BC/BCE notation; by convention year zero is labelled positive: +0000. Note the addition of a year zero causes earlier years to be different by one when converted; for example, the year 3 BC would be denoted by −0002."

"+0000" can also mean the first century [section 4.1.2.4d], and "-0002" can also represent a century.

"For example, one may write "1981-04" to mean "1981 April", and one may simply write "1981" to refer to that year or "19" to refer to the century from 1900 to 1999 inclusive."

One may also write "+1981", which could mean either the year 1981 [4.1.2.4c] or the 1982nd century [4.1.2.4d].

More ambiguities:

Section 4.4.5 permits an interval such as

 T143058-05/2013-04

which complies with all syntactic requirements in 4.4.5 and relevant sections, and requires no agreement. As such it is perfectly legal. It is also impossible to unambiguously interpret as a time interval. On the other hand, the incomplete date in April 2013 is known to be specified as associated with a time zone 5 hours West of UTC, which seems to be the only way to attach a zone or zone offset to a date.

Fractional durations are permitted, but not clearly described in terms of semantics. E.g., in "P1.1Y" what exactly is a tenth of a year? 1.2 months? 36.5 days? 36.52475 days? 36.6 days if the specific full year is a leap year? 36.6 days also if the tenth of a year includes a February 29th? Even if a specific calendar date is provided, there are multiple ambiguities. For example try to list the date-times of the intermediate and final instants of the following recurring time intervals:

   R7/1992-06-28T12:34:56-01:00/P1.1Y
   R7/1992-06-28T12:34:56-01:00/P13.2M
   R7/1992-06-28T12:34:56-01:00/P401.5D

[note that the span must include at least one leap year, includes multiple leap seconds, and may include discontinuities due to Summer/Winter time (but whose rules for a local time zone 1 hour West of UTC? (and what if some darned politician changed the rules somewhere along the way?))] 68.186.246.74 (talk) 03:41, 28 April 2013 (UTC)

Do you have some specific suggestions as to how we might improve the article? Mitch Ames (talk) 06:03, 28 April 2013 (UTC)

Noting the ambiguities at appropriate points, aside from documenting issues with the standard, would alert generators and consumers of data in the format to potential problems. 68.186.246.74 (talk) 13:03, 28 April 2013 (UTC)

What you've written above is perhaps a bit wordy, but there may be merit in adding an Ambiguities section the article with a few of the more likely scenarios - if you can provide references to where they may have actually been a problem, or other cites agreeing that there is ambiguity, otherwise we have a risk of original research.

The "ambiguities" where a given sequence can represent either a date or a time (eg "2004-05" being April 2004 or 8:04pm 5 hours west of UTC) may not be relevant, because the standard says (with my emphasis):

3.3 Representations and format representations

...

By mutual agreement the parties in information interchange may transfer the date and time format representations.

This suggests to me that the parties must agree in advance as to whether date or time or both are being exchanged - thus there is no ambiguity because we are required to agree in advance whether we are writing a date or a time. Naturally you may differ in your interpretation - which is why we need to cite a reliable secondary source as to how the standard (a primary source) should be used.

Likewise your example "+1981", which could mean either the year 1981 [4.1.2.4c] or the 1982nd century [4.1.2.4d] is incorrect because 4.1.2.4 says "The interchange parties shall agree the additional number of digits in the time element year". Ie we must agree in advance that we will add zero digits (+1981 is a year) or two digits (+1981 is a century).

I suggest quoting any proposed wording of a new "ambiguities" section here (or on a subpage) for review before adding it to the article. Mitch Ames (talk) 13:25, 29 April 2013 (UTC)

There are a number of issues with the "mutual agreement" mentioned several times in ISO 8601:

• It presupposes a single-writer, single-read model which simply doesn't work in other modes

• an author cannot reach agreement in advance of publication with all possible future readers

• not to put too fine a point on it, but the author(s) of the article cannot have reached such agreement with all possible future readers, for example
• an author might specify (necessarily separate from the content; see below) what is being presented, but that is more "dictatorial fiat" than "mutual agreement"

• compilations from multiple sources (e.g. syslog, conference proceedings, and the like)

• The format itself contains no provision to carry information about any such "agreement"

• therefore, when excerpted or otherwise presented out of a single-writer, single-reader context such information is likely to be unavailable

• and this is how some of the ambiguities present themselves; given only "2004-05" one cannot know if there was any "agreement" to transfer date or time

• in several cases, it is unnecessary as no ambiguity will result (e.g. number of digits in a fraction)

• to the point of one of the above examples. "+2004-05" is unambiguously a date (not a time) and unambiguously has exactly four digits in the year

68.186.246.74 (talk) 20:51, 29 April 2013 (UTC)

3.3 Representations and format representations

...

By mutual agreement the parties in information interchange may transfer the date and time format representations.

Note carefully the difference between a "representation" and a "format representation"; the latter is what requires agreement.

See definitions in sections 2.3.1 and 2.3.2.

68.186.246.74 (talk) 22:18, 29 April 2013 (UTC)

Commons category - proposed deletion

This edit added a link to Wikimedia Commons category ISO 8601. That category has been proposed (by me) for deletion. Interested parties may care to contribute to the discussion on Commons. Mitch Ames (talk) 02:44, 8 June 2013 (UTC)

BCE and divs

The class should apply equally well to divs. As we are not presenting tabular data, it is advisable to use divs.

Either BC or BCE (and AD or CE) should be used, but not both. I favor CE, if only because it's not Latin, and not religious. (Ideally, time shouldn't be religious, but we are talking about the Gregorian calendar.) However, I don't really care, just as long as we're not using both. It was by carelessness that I added BCE instead of BC—I was focusing on clear prose, so I ignored a distracting debate. (Careless, as in without worry, not haphazardly.) —Daelin @ 2006–01–08 16:21Z

Since this was written, WP:ERA has been adopted, which calls for deciding between BC and BCE by which was used in the first non-stub version of the article. As it happens the first version of this article uses BC, so I will correct the usage in the article accordingly. Jc3s5h (talk) 19:50, 4 July 2013 (UTC)

BC

BC dates are handled in ISO 8601 with a minus symbol. Beware that before AD 1 (0001) there is, BC 1 which is 0000, so BC 2 is -0001 and so on. I found a draft copy of the standrd at http://www.ray-connolly.fsnet.co.uk/ISO8601-2000_Draft-20001215_ISO-TC154-N362_Final.PDF (anon)

< In spite of "This is not a forum for general discussion of the article's subject." Ceterum censeo that we should not support this logical nonsense! That educated "scientists" are unaware of the difference between a timeSPAN, here the notion "year", against a POINT in the time scale, here "zero", is in fact remarkable, politely expressed. Regarding a temperature scale, everybody naturally uses "zero degrees (Celsius/Fahrenheit" for a rough temperature notion at roughly the zero-crossing of the temperature scale. Knowing very well that this would not create a span of zero degrees. Obviously some astronomists are unable to cope such logical interrelations, but take very much money for a copy of it.HJJHolm (talk) 10:51, 10 January 2014 (UTC)

Time Intervals

I have a problem with the interpretation of <start>/<end> intervals. There is an example in the text that "2007-11-13/15" could be expanded to "2007-11-13T00:00/15T24:00". Well, that is logically wrong. I don't know where the error lies, in this wiki article or the iso-8601 standard itself (i couldn't get a copy). "2014-03-14/2014-03-15" surely means 24 hours like "2014-03-14T10/12" covers only two hours instead of the suggested three. This is how dates are handle in praxis (eg see ical), the same logic must be applied to all elements. It doesn't mean from .. including to, rather include from .. exclude from.

2007-11-13/15 can be read as "any time on 2007 November 13 to any time on 2007 November 15", ie including at least part of the first and last days. So the duration could be anything from just over 1 to just under 3 days. As the article says, if a more precise time is required, it could be 2007-11-13T00:00/15T24:00, but it could also be 2007-11-13T23:59/15T00:00 (just over one day).

Similarly 2014-03-14T10/12 could be anything between about 1 hour (10:59/12:00) and 3 hours (10:00/12:59).

You appear to be assuming that the time of day denoted by each of 2007-11-13 and /15 has to be the same (nominally the start of day) - it does not. If you want a specific time within the day you need to specify it.

That being said, the article does need rewording, because 2007-11-13/15 is not the same as 2007-11-13T00:00/15T24:00. Mitch Ames (talk) 03:52, 15 March 2014 (UTC)

I've updated the article accordingly. Mitch Ames (talk) 04:03, 15 March 2014 (UTC)

Unix ddate

Suggest covering the Unix ddate command. ;-) 195.212.29.90 (talk) — Preceding undated comment added 09:13, 14 May 2014 (UTC)

Clauses or sections

The article currently uses both "clause" and "section" to denote numbered clauses/sections of the standard, but ideally we would use only the one term. I was of the view that ISO used the term "clause" in its standards - eg ISO/IEC 7816 does - but searching through 8601 I find no use of the term "clause" and two usages of "section" (in 4.4.3 and 4.4.5, but referring to other numberer sections).

Should replace "clause" with "section" in our article, where referring to sections of 8601? Mitch Ames (talk) 08:54, 10 August 2014 (UTC)

Clause refers to a group of sections. Section refers to a specific section within a clause. ie: "Clause 4" is everything from 4 to 4.5.4. While section 4.2.4 applies to that specific point. JMJimmy (talk) 09:07, 10 August 2014 (UTC)

fixed them all JMJimmy (talk) 09:14, 10 August 2014 (UTC)

words or non-character are not part of the standard

I've deleted this:

With the exception of day of the week, words or non-character are not part of the standard.

from the Week dates section, because the days of the month are part of the standard. What the standard actually says is that it "does not cover dates and times where words are used in the representation and dates and times where characters are not used in the representation". If we want to include that information, it needs to be paraphrased more accurately, and in a section that covers more than just week dates. Mitch Ames (talk) 13:28, 12 August 2014 (UTC)

What section do you think is appropriate? (also I forgot to include month names along with day of the week) JMJimmy (talk) 17:01, 12 August 2014 (UTC)

A brief summary of the scope is appropriate in the lead section - thus. Mitch Ames (talk) 11:24, 14 August 2014 (UTC)

Gregorian calendar and ISO 8601

The authors of ISO 8601 felt the need to describe the Gregorian calender so it was unambiguously defined, (or in a sense, they were unambiguously defined) without relying on any of the documents related to the calendar that were written by the Roman Catholic Church. But that does not mean Wikipedia has to repeat that formulation. Although some historical variations and some variations used in limited geographies exist, there is one Gregorian calendar that is used for daily secular life in Europe and many countries who's development was strongly influenced by Europe (Australia, Canada, Mexico, and the United States, to name a few). So all we need to do is make it clear that the familiar international commerce version of the Gregorian calendar is the one used in the standard, together with the proleptic Gregorian calendar.

The standard also allows for the possibility of using a week representation, such as 2014-W33-5 for today. We have an article about it. A feature of this week-based system is that the year does not change in the middle of a week, so although derived from the Gregorian calendar, it isn't really the same calendar. Nachum Dershowitz and Edward Reingold in Calendrical Calculations have a short chapter, 5, devoted to this. They don't call it (or them) the Gregorian calendar; they call it "The ISO Calendar". So when I write "Gregorian calendar" I am excluding variations that prevent the year from starting mid-week.

Obviously the Gregorian calendar was introduced when there were no good clocks; today we have the possibility of deciding when days begin and end by referring to atomic clocks, and ignoring the passage of the Sun across the sky, but that was not possible in the 16th century. So the Gregorian calendar counts days, and until the introduction of standard time, it was implicitly the count of days in a particular location. There are an infinite number of ways to use the Gregorian calendar, depending on where the observer is counting days, but these are not considered different calendars, just different locations.

So if someone wants to convince me that the international commerce version of the Gregorian calendar is different from the calendar that ISO uses when representing dates in the form YYYY-MM-DD, let them prove a concrete example that results in a different date depending on which one you use. Jc3s5h (talk) 20:04, 15 August 2014 (UTC)

Aside from the RFC3339 you quoted doing just that, http://www.math.harvard.edu/computing/javascript/Calendar/ Enter a date of 2000-01-01 (completion of an earth rotation is set at midnight so leave the time as 00:00:00). Hit calculate and scroll to ISO-8601 Week and Day, and Day of Year. ISO shows Day 6 of week 52 of year 1999 where Gregorian is Day 1 of year 2000. Joys of the 26 second problem. After 3,323 years Gregorian will be 1 day off. Who cares right? It'll be almost the year 5000 before it becomes an issue and we'll be long dead! Who cares! Problem is, if the world were on true Gregorian calendar right now, midnight would be at about 8:54pm. We're already over 3 hours off JMJimmy (talk) 20:55, 15 August 2014 (UTC)

There are two problems with your post. The first problem is "scroll to ISO-8601 Week and Day, and Day of Year". I wrote above "So when I write "Gregorian calendar" I am excluding variations that prevent the year from starting mid-week." So the fact that 2000-01-01 could also be represented 1999-W52-06 is not what I am discussing; we have a different article about that, as well as a section within this article.

The second post is "After 3,323 years Gregorian will be 1 day off." Off from what? Timekeeping (figuring out the time of day) has traditionally been a separate subject from calendars. It has always, right from the introduction of the Gregorian calender, to be perfectly normal to keep it with many different timekeeping authorities, and still call it "the Gregorian calendar". The original goal of the Gregorian calendar was to keep Easter throughout the world on the same day; the day that the creators of the calendar considered correct according to their religious beliefs. But each and every church (as in a church building) that adopted and observed the Gregorian calendar kept time differently because they were in different locations. So if one guy wants to hypothesize that days will be counted by physical passages of the Sun at a particular location, and another wants to hypothesize that the Gregorian calendar will be used together with International Atomic Time, and they have a meeting and observe that after 3000 or so years the two of them would be observing Easter on different days, so what? They're just using different timekeeping methods, which has been perfectly normal ever since the Gregorian calendar was introduced.

More to the point, ISO 8601 doesn't say which timekeeping method to use, it just gives some options to indicate the timekeeping method if you want to. Jc3s5h (talk) 21:38, 15 August 2014 (UTC)

Point 1) while the calculator just shows the week, the actual dates are 2000-01-01 vs 1999-12-31. The week and day of week are not important to the point I was making.

Point 2) Easter has nothing to do with anything so please lets just ignore it. The rules for the general use Gregorian calendar are quite simple, from midnight on 1582-10-15 they began counting 24 hour days, 60 minute hours, 60 second minutes (along with the leap rules). The reason is simple math. If you calculate the earth's rotation around its axis and rotations around the sun etc the time that has elapsed will not match the same equation calculated using the Gregorian calendar. That's why the edit that you keep deleting in the Gregorian calendar article is actually somewhat important (in spirit anyway). When you calculate to the second the Gregorian calendar has fallen behind the Earth's rotation by ~11,254 seconds. UT standards and ISO 8601 correct for that mistake, just like Gregorian corrected for the ~0.002% mistake in Julian.

Point 3) Yes it does say what timekeeping method to use, it builds up from the SI defined second through to calendar years, etc, in a very specifically defined time scale. JMJimmy (talk) 23:03, 15 August 2014 (UTC)

Your statement "while the calculator just shows the week, the actual dates are 2000-01-01 vs 1999-12-31" is not true. When the date January 1, 2000, time 00:00 is entered into the "Gregorian calendar" section of converter you suggest (and which I use myself quite a bit through a different URL) the representation 1999-12-31 does not appear anywhere on the page. What does appear in the "ISO-8601 Week and Day, and Day of Year" is Day 6 of week 52 of year 1999. Note this date is not in the "Gregorian calendar" section. If you think ISO 8601 claims this is a Gregorian calendar date, I disagree with that reading. A secondary source seem to agree: Dershowitz and Reingold don't say the week-based calendar is the Gregorian Calendar. Can you show a case where a date stated in the modern international commerce version of the Gregorian calendar would be represented by a different date in the form YYYY-MM-DD?

Your point 2 makes no sense. Your point 3 is an incorrect reading of the standard. Jc3s5h (talk) 13:35, 16 August 2014 (UTC)

Point 1)It doesn't need to show the -12-31. One shows the year 2000, the other shows the year 1999. That's enough, they are different years no matter what. They are obviously not the same date and basic logic/math allows you to figure out the -12-31.

Point 2)If my point 2 makes no sense then you obviously don't understand the foundation of calendars/dates/times.

Point 3)Ok, lets be clear - I am not saying the timekeeping system is UTC/non-UTC/Gregorian/etc. I am saying that 2.2.1 through 2.2.4 detail a 24 hour timekeeping system — Preceding unsigned comment added by JMJimmy (talk • contribs) 14:12, 16 August 2014 (UTC)

Your points 2 is unworthy of response, and I will defer consideration of point 3. Point 1: Given the statement, in a modern international commerce context "January 1, 2000 of the Gregorian calendar", the standard would allow it to be represented "2000-01-01" or "1999-W52-06". Given the statement, in a modern international commerce context, "year 1999, week 52, day 6 of the ISO 8601 week calendar" the standard would allow the same two representations, "2000-01-01" or "1999-W52-06". You cannot supply any example where a date in the international commerce version of the Gregorian calendar, stated in the form "year y, month m, day d" should be represented, according to the standard, in the form "Y-M-D" where y ≠ Y, m ≠ M, or d ≠ D (disregarding leading zeros or difference in convention for indicating years before 1) Jc3s5h (talk) 14:31, 16 August 2014 (UTC)

Point 1) I have no clue what you're saying. It all relates back to point 2, which you can ignore all you want, the simple fact is that time systems like these are all just representations of the Earth going around its axis and its rotation around the Sun. Julian, Gregorian, and ISO are all trying to represent a day as 1 rotation of the Earth around its axis and a year as 1 rotation of the Earth around the Sun. The difference between the them is the accuracy with which they do so. Julian was ~0.002% off the axis rotation, Gregorian is off by ~0.07 seconds per axis rotation, ISO - while it can be used to express any of them - in its "modern international commerce context" can be as accurate as atomic time or as in-accurate as UTC. Technically speaking, international commerce context it's probably more the "Microsoft" timekeeping system or the Unix timekeeping system more than the ISO. JMJimmy (talk) 15:31, 16 August 2014 (UTC)

Point 1) "I have no clue what you're saying." When I'm right, you say you don't understand me. I cannot continue a discussion with a person who adopts such tactics. I will ignore you from now on. Jc3s5h (talk) 15:56, 16 August 2014 (UTC)

LOL omg you gave me a great laugh. "Your point 2 makes no sense" - Jc3s5h. It seemed perfectly fine when you did it to me. The difference between the two is, I didn't have a clue what you were saying, because it logically did not make sense that the year 2000 was equal to the year 1999. You said "the standard would allow it to be represented "2000-01-01" or "1999-W52-06"" which is true where the former uses Gregorian calendar rules and the latter uses the ISO standards rules. Gregorian does not use leap seconds, period, full stop. Normative Note 2 of the definition of a calendar day should tell you all you need to know: "The duration of a calendar day is 24 hours; except if modified by" a leap second. JMJimmy (talk) 17:06, 16 August 2014 (UTC)

I'm sorry, I realize after re-reading that was a bit rude, I apologize. It also gave me the idea of how it might be easier to visualize:

Gregorian calendar = 60*60*24*(365 + leap day) = 1 calendar year in seconds

ISO calendar = ((60*60*24) + leap second)+(60*60*24) + leap second)).... repeated (365 + leap day) times = 1 calendar year in seconds

"leap day" = (60*60*24) in appropriate leap years

"leap second" = +/- 1 as appropriate by decision of IERS.

Very different calculations JMJimmy (talk) 17:31, 16 August 2014 (UTC)

Readability and context.

The dates section of this article begins "The standard delineates Gregorian calendar to mean a, possibly infinite, time scale of adjoining calendar years that has a reference point as well as several properties and limits. The properties include continuous/sequential numbering of years..." This is not gramatically readable nor does it provide any context. I don't care too much about the factual accuracy of it or any other versions, but if this paragraph is going to stay for any significant amount of time it needs to add context and be phrased in a way that is readable by the average reader. CombatWombat42 (talk) 17:57, 13 August 2014 (UTC)

Readability issue is agreed by all, including myself, and was under discussion above before it got side tracked. I'm not sure what you mean by context in this case, could you elaborate? JMJimmy (talk) 19:11, 13 August 2014 (UTC)

Pulled out of the previous derailed conversation.

The sentence, expanded or otherwise, is intended to include these elements: 1) The standard is defining a specific version of the term "Gregorian calendar" (not that it merely states*) 2) That the term "Gregorian calendar" is a time scale 3) The time scale could be infinite 4) The time scale is comprised of adjoining years (adjoining has much the same meaning as "series of contiguous") 5) The time scale has reference point (1875 signing) 6) The years have 52-53 weeks 7) The years are continuous and sequential (this language is hard to avoid) 8) The years are comprised of 365 or 366 days 9) Each year contains 12 months 10) Each month individually has a number of days 11) Those days are detailed in the standard

If expanded into something more verbose, the separation must not cause any attributes described in 1-10 to be lost, changed, or improperly attributed. It should also not cause any confusion between the term being defined and the traditional term. (*I avoided the use of "define" so that it would not be easily confused with the "definitions" section which defines the basic traditional meaning for the term). How best to accomplish all of the above in a more readable way I'm not sure of. JMJimmy (talk) 19:22, 13 August 2014 (UTC)

I have not previously edited this article but was asked to comment by Jc3s5h. I found the first few paragraphs readable and have inserted a request for clarification of one point I was unable to follow. When I got to the section beginning "The standard delineates Gregorian calendar ... " I found it impenetrable, and don't see the point of including it in its present form. I have read it 3 times and I still don't get it. Why not edit the text here on the Talk page first? Dondervogel 2 (talk) 11:35, 15 August 2014 (UTC)

Please excuse the lack of indenting and length.

The documentation state of the ISO standards on Wikipedia is woefully poor. List of International Organization for Standardization standards lists many of them and of the ones that aren't unlinked/red-linked a bunch are re-directs back to that page (like ISO 19108). These standards are incredibly important as their referenced by the highest levels of industry/science and trickle down through other standards like the internet RFCs. I do not claim to be an expert on them by any means, however, I am able to recognize a significant portion of what is written about them is simply not factually accurate. Being written at such a high level they are also incredibly dense grammatically (a sentiment echoed by the RFC which I quoted above) and can very easily be misinterpreted. Another part of the problem is that they're not open standards so unless the documents leak or are provided free they're not likely to end up in the hands of very many people (they're also very protective and DCMA a lot). The result is very little in the way of quality secondary sources. For each ISO I could dig up dozens different interpretations of any given standard from secondary sources. Especially secondary sources that are applying a given standard, though nothing that should ever be considered a quality source.

The reason they should never be considered quality sources is because many of those interpretations can be accurate to the scope and implementation of their application and agreements. If put on the same plane as another project with a similar, but slightly different scope/implementation/agreement the former would not meet the standard while the latter would. Confusingly, the reverse can also be true without changing anything. So how can both be "right" and "wrong" at the same time? A lot of it comes down to the contents of the ISO/IEC Directives. Part 2 is a 72 page standard on how to write and interpret the standards that includes 31 ISOs/documents in its normative references alone. There are also ISO/IEC "Guides" which provide "rules, orientation, and advice or recommendations", there are corrigendums which make corrections without publishing a revision of the standard, actual revisions of the standard, superseding of standards by others in part or whole, and ISO/TCs which must be taken into consideration.

Thrown for a loop yet? It gets more complicated. Where a document doesn't supersede another and where they both have a term defined, the one which defines the concept first is the definition to be used in the later but only so far as it can within its scope. If outside its scope the newer definition applies so long as it is still homogenous with the concept as a whole through all docents. Another aspect is that notes in the definitions section have a different set of rules and interpretation than notes within the text. Notes in the text can only give information for understanding the document, they can't make any sort of normative requirement (ie: they can never use: shall/shall not, should/should not, can/cannot, may/need not). They can state fact though. Notes in the definitions section can use those statements to provide normative requirements, supplemental definition, provisions for use, etc. Annexes, footnotes, tables, and figures (and combinations there of) are similarly complicated.

Ready for the curve ball? Even given all of that there are two elements which can completely twist your mind inside out trying to figure them out. First, the clauses and subclauses (sections) are somewhat severable. That's to mean that, based on the structure of the document the standard changes what is required, recommended, stated, or severable to a particular use for the standard. A simple example they give is:

• Part 1: General requirements
• Part 2-1: Requirements for plasma displays
• Part 2-2: Requirements for monitors
• Part 2-3: Requirements for LCDs

Clause 1 (part 1) applies to all subsequent clauses/subclauses. Clause 2 though is severable based on the application. If I am using the standard for a LCD TV I can sever subclauses 2-1 and 2-2 from the standard and still be compliant since they're not in the scope of my application. If I'm making an LCD monitor though, I cannot sever section 2-2 because it is within the scope of my application. Note I said "somewhat severable" before, lets say subclause 2-3 has 2 subclauses 2-3-1 and 2-3-2. If I am making an LCD TV and 2-3-1 makes a dated or undated reference to clause 2-2 that means that can't sever 2-2 if I want to be compliant. (dated/undated reference being "2-3-1 blah blah blah (see 2-2) blah blah"). And then comes the final twist:

A document does not in itself impose any obligation upon anyone to follow it. However, such an obligation may be imposed, for example, by legislation or by a contract. In order to be able to claim compliance with a document, the user needs to be able to identify the requirements he/she is obliged to satisfy. The user also needs to be able to distinguish these requirements from other provisions where there is a certain freedom of choice.

Because of the use of "may be imposed" (this concept is echoed so many times with the "by mutual agreement" type of phrase in some documents) it means that there might or there might not be an obligation depending on the situation. In the TV example, if 2-2 wasn't severable but my contract/the law/etc made no requirements for it I could still chose to ignore it and technically be compliant because my agreement/scope of my application overrode the standard (or made irrelevant). Its discussed in various ways but basically they don't want the standard to become so rigid as to hold back an improvement in tech/science/etc. Their approach shows a preference for a general, more flexible, yet reasonably consistent standard which can be re-written in part or whole as the world changes. Anyway, all of this is just a very short (hahaha) summary of the 2nd half of 1 the ISO/IEC directives that didn't even touch on certain parts of it.

Crazy eh? So the point of all this (that is if you're still awake/sane ;) is that these standards, if they're ever going to get any sort of quality, are going to need to do so via reasonable, carefully considered, analysis & reasonable synthesis of the primary source(s). They'll require a higher level of discourse than is typical and even then they'll need heavy revisions to unpack the language and important aspects of the documents in a reasonable, encyclopedic fashion. In the same way that I will never understand what Quantum_harmonic_oscillator or Butyl articles are talking about, some may not understand these standards. I would not expect those articles to be dumbed down and made inaccurate/misleading/false simply so I could get a basic (&flawed) grasp of the topics. That said, I do think it is possible, to a certain degree, to unpack the language into a more readable format. That will likely take years to accomplish with the current state of the ISO series. It needs to start with information that is as accurate as possible, creates as little synth as possible, and then unpacking can follow. If it starts with unpacking there will be no baseline for accuracy and synth and falsehoods will find their way in with ease. The most recent addition to the page highlights this perfectly:

In general, ISO 8601 is limited to dates in the Gregorian (and potentially proleptic Gregorian) calendar, times based on the 24-hour timekeeping system, and combinations and intervals thereof.[1] It only applies when the dates and times are to be represented by numerical characters[1] (e.g. month numbers 1 to 12 rather than names January to December) and possibly separator characters (such as the colon in the time denoted "12:35").[2]

Knowing that notes in definitions provide normative supplements the "Gregorian calendar" definition includes: "NOTE In this International Standard the term Gregorian calendar is used to refer to the time scale described in 3.2.1". So right away we have inaccuracies & synth because the Gregorian/proleptic Gregorian calendars in general use are not the ones being described in the 3.2.1 time scale (close as they are). The more informational clause 5 tells us "if applicable, if the interchange of date and time representations derived from the date and time format representation has been agreed."... how can one derive something from the format of itself? Because accuracy was sacrificed for readability a massive chunk of the scope was left out. Namely, the "or of the formats of these representations". Once included, deriving from a format of one of the 3 listed representations makes a lot more sense all of the sudden. An interchange of an ISO 8601 compliant date representation, derived from a Julian calendar date in the format of a Gregorian calendar representation, is not outside the scope if it "has been agreed". The simple omission of 7 words radically changes the applicability of the standard and the reading of the rest of the article. In fact, while I haven't got a hold of it to verify the language, my understanding is that ISO 19108 actually provides a standard for making the calculations from Julian to the ISO 8601 time scale. The 2nd sentence is just as bad, the standard states it does not cover representations where characters are not used (ie: non-number characters can, and are used) or where words are used. The latter seems to indicate Jan/Dec are not covered - I initially made this mistake myself. 1 January 14 is a valid Gregorian format and can be derived just like a Julian calendar date. The interchange does not use words (though it does use non-numerical characters like R/P1Y2M15DT12H/1985-04-12T23:20:50) but the deriving of the date can use specific words, listed in the standard, which have been assigned meanings. Each language of the ISO specifies the exact words which correspond with the month/day of the week. ie: French's ISO 8601 lists Février = 02 the same way the English version lists February = 02. They don't assign meaning to words/phrases/characters like "Year of the Rooster" for the Chinese calendar so those cannot be derived... without agreement ;) (gotta love that mutual agreement portion).

Sorry for the essay - I really didn't intend for it to stretch out like that but I think it's important people understand I'm not trying to be tendentious or disruptive. I think the subject matter is interesting and a challenge to understand at times let alone distill into encyclopedic content (if that's even possible lol). At the same time it's one that has been widely misunderstood as a result of that challenge and never risen to the level of quality due such a globally important series of topics. JMJimmy (talk) 17:25, 15 August 2014 (UTC)

... via reasonable, carefully considered, analysis & reasonable synthesis of the primary source(s).

Analysis and synthesis of primary sources is not the role of Wikipedia. WP:PRIMARY makes that clear thus:

Do not analyze, synthesize, interpret, or evaluate material found in a primary source yourself ....

Frankly, that is what you are doing, JMJimmy, and you ought not.

Again from WP:PRIMARY:

Do not base an entire article on primary sources, and be cautious about basing large passages on them ...

This is what we all appear to be doing (myself included) and we probably ought not be. We should limit ourselves to "straightforward, descriptive statements of facts that can be verified by any educated person with access to the primary source but without further, specialized knowledge" You've described above how difficult it is to interpret the standards - it's clearly a specialist job, which means we ought not be doing it. This means that a lot of the detail probably ought to be removed. I don't believe we should be trying to include every detail of a technical standard into the article - we're not doing our readers any favours by trying. The nature of technical documentation is that any attempt to "reword" it (either to clarify it, or to avoid copyright issues) is likely to change the meaning of it. Perhaps we need to accept that we are trying to do too much - what we should be doing is giving an overview of the basic principles and not trying to get every little obscure detail correct. Mitch Ames (talk) 13:48, 16 August 2014 (UTC)

The most recent addition to the page highlights this perfectly:
"In general, ISO 8601 is limited to dates in the Gregorian ..."
... right away we have inaccuracies & synth because the Gregorian/proleptic Gregorian calendars in general use are not the ones being described in the 3.2.1 time scale ...

That paragraph is in the lead section; it's intended to be a simple overview of the keys points (per WP:LEAD) of the scope/purpose of the standard and when it is appropriate to use it, not include every detail, hence the first two words In general. You're evidently not happy about my use of "Gregorian calendar" in that paragraph. However the intent of that paragraph is the same as section 1 Scope of 8601, which says (with my emphasis here)

This International Standard is applicable whenever representation of dates in the Gregorian calendar, ...

If it's good enough for the standard itself to summarise with that term I think it's probably OK for Wikipedia to do the same. Mitch Ames (talk) 13:57, 16 August 2014 (UTC)

The 2nd sentence is just as bad, the standard states it does not cover representations ... where words are used. The latter seems to indicate Jan/Dec are not covered
I did not use the word "cover", I said "represented by", ie 8601 applies when dates are to be represented by numbers, not words; 2014-08-16 (numbers, not words) is a valid 8601 representation of the date, but 16 August 2014 (includes words) is not, because months are represented as numbers 1-12, not words Jan-Dec. Mitch Ames (talk) 14:01, 16 August 2014 (UTC)

I moved your text outside of mine as it makes it confusing to read with interruptions especially in the middle of a paragraph. I completely agree we are all using WP:PRIMARY in rare cases like this its almost impossible not to. As to the lead, "key points" is the key point, by omission of the 4th key point of the scope you change the average person's reading. You also state that, while in general, it's "limited to dates in" - it's not "limited to", it's "applicable to" "representations of" - two radically different statements. Combining that with the omission it reads as though it can only be used, in general, for Gregorian calendar dates. JMJimmy (talk) 14:48, 16 August 2014 (UTC)

interruption confusion...missed one. Regarding the 2nd sentence: R/P1Y2M15DT12H/1985-04-12T23:20:50 is valid ISO8601 but contains non-number characters. JMJimmy (talk) 14:55, 16 August 2014 (UTC)

I've inserted into my post of 13:57, 16 August 2014 (UTC), which you moved, a quote from your post to make it clear which paragraph I was talking about. Mitch Ames (talk) 02:19, 17 August 2014 (UTC)

I moved your text outside of mine as it makes it confusing to read with interruptions ...
It would be helpful if, in your posts, you could put specific criticisms of article edits (eg the paragraph I added) into separate posts and (where applicable) separate paragraphs to cover separate points (eg 1st and 2nd sentence of the para that I added), rather than including those criticisms buried in a long essay that covers a range of material. That will make it easier for me to reply in a manner that is meaningful, without interrupting your posts. Mitch Ames (talk) 03:40, 17 August 2014 (UTC)

I completely agree we are all using WP:PRIMARY in rare cases like this its almost impossible not to.
As I pointed out (with quotes from WP:PRIMARY) we can use primary sources (the ISO 8601 standard itself, in this case) as a source about which we make "straightforward, descriptive statements ...", but analysis is simply beyond the scope of Wikipedia, and we should not do it - that's not just my opinion, it's a core policy.

I've also mentioned this disagreement about policy at the ANI entry. Mitch Ames (talk) 04:31, 17 August 2014 (UTC)

As to the lead, "key points" is the key point, by omission of the 4th key point of the scope you change the average person's reading.
("4th key point of the scope" is "local time based upon the 24-hour timekeeping system".) I think you're unnecessarily speculating about what the reader might (mis-)read into a simple statement - "24-hour timekeeping system" does not exclude time zones. My original sentence was, intentionally, a very broad overview. However, I agree that time zones are important, so I've added them to the sentence. Mitch Ames (talk) 07:01, 17 August 2014 (UTC)

You also state that, while in general, it's "limited to dates in" - it's not "limited to", it's "applicable to" "representations of" ...
Fixed. Mitch Ames (talk) 07:04, 17 August 2014 (UTC)

Regarding the 2nd sentence: R/P1Y2M15DT12H/1985-04-12T23:20:50 is valid ISO8601 but contains non-number characters.
My original wording was intended to include those non-numbers, in general (while keeping it simple with an example that the average user would recognize), as "separators". However:

• Some such characters don't actually separate, eg leading R or P, and trailing Z.
• 8601 uses "separators" and "designators" as independent terms.

So these edits address that problem. Mitch Ames (talk) 07:12, 17 August 2014 (UTC)

I think this change by Mitch Ames, while acceptable, does not address this thread, because this thread is about the text between the start of the "Dates" and the start of the first subsection ("Years") and the edit was made to the lead section.

If it is felt anything more needs to be said about dates that is not contained in the lead, but is also not contained in any of the subsections ("Years", "Calendar dates", "Week dates", and "Ordinal dates") then naturally any such statement would go into somewhat more detail than the lead, without being unreadable. Since this is the Dates section, it should not be delving into times. At most, it should say that the date representation may be used by itself, may be omitted if the data exchange partners only wish to represent the time of day, or may be combined with a conforming time representation. It would be helpful to find a clear-cut citation to say what the meaning is of a date representation that is not combined with a time representation. For example, if only a date representation is used in the context of a culture which considers the day to begin at sundown, does the date representation mean a day that begins and ends at sundown, or does it mean a day that begins and ends at midnight? Jc3s5h (talk) 16:16, 17 August 2014 (UTC)

nor does it address representations that use unspecified words

This edit introduces the following, into the lead section:

nor does it address representations that use unspecified words (e.g. year names in the Chinese calendar) ...

I don't believe this is a complete statement of the facts as expressed in the penultimate paragraph of 8601 section 1 Scope, which says (with my emphasis):

This International Standard does not cover dates and times where words are used in the representation ...

The standard does not limit its exclusion (in representations of dates/times) to "unspecified words", just "words". In particular the standard does not cover the case where the word "August" is used in the representation of the date, even though "August" is a "specified word" (it is included in Table 1 Calendar months). @JMJimmy:, if you still think your wording is correct, could you please provide an example of a representation of the date (where the word representation has the meaning implied by its use in various definitions in section 2.3 Representations and formats, and 3.4 Characters in the representations) that uses a "specified word". Such an example would easily demonstrate the necessity for including "unspecified" in the sentence. Mitch Ames (talk) 12:27, 17 August 2014 (UTC)

Considering that most readers won't have access to the standard, that the passage is in the lead, and that most languages do name months and do not name years, the passage as it stands will be understood to mean that month names are allowed in conforming representations, which is false. This impression will prejudice their reading of the rest of the article, and they may not be able to figure out from the rest of the article that month names are not allowed. (In my posting "month name" means a written name for a month using characters of the Roman alphabet, with or without accented characters.) Jc3s5h (talk) 15:42, 17 August 2014 (UTC)

omg... I think I may have clued into where the difference in interpretation might be coming from. When I read an ISO scope I do so with this in mind:

This element shall appear at the beginning of each document and define without ambiguity the subject of the document and the aspects covered, thereby indicating the limits of applicability of the document or particular parts of it.

I don't think they succeeded in this case. I read the subject to be the time point/time/time interval and formats as they existed pre-standard. e.g. 31/05/1999; 05/31/1999; 1999/05/31; May 31, 1999; 31 May 1999; etc those examples being representations or formats of dates in the Gregorian calendar. ie: The ISO is applied to the subject to result in a compliant representation for interchange. The way, if I'm understanding correctly, you are reading it is that the subject is the representation for interchange (e.g. 1999-05-31). ie: The ISO is applied to the subject to result in a compliant subject. In the latter the "words" statement is then taken to mean it doesn't concern itself with interchanges of "May 31, 1999; 31 May 1999; etc" and makes no attempt to standardize or interchange them. Both views make sense to an extent, however, for the latter interpretation I can't reconcile the contents of Table 1 and 2. If we're referring to a representation used in interchange then month/day names never come into play because they're not covered per the "words" rule. If they're never used, why list them? On the other hand, taking the former reading of it, when you come across a "May 31, 1999" or the like, Tables 1 provides an index to interpret May as 05. Table 2 acts similarly for day of the week. The "words" statement remains intact to its meaning, just that for its purpose May is "05" not a word. JMJimmy (talk) 16:52, 17 August 2014 (UTC)

Concerning this quotation from an unstated source, which I infer to be some wide-ranging document about how ISO standards should be written:

This element shall appear at the beginning of each document and define without ambiguity the subject of the document and the aspects covered, thereby indicating the limits of applicability of the document or particular parts of it.

I read "subject" to mean the topic of the standard. I don't think it means something that a standard-compliant process will act upon to produce a standard-compliant result. An example of something that is not a subject of the standard is a recurring time period that is to occur the last Thursday of every Gregorian calendar month. The sentence in question is

Nor does it address representations that use unspecified words (e.g. year names in the Chinese calendar) or that do not use characters (e.g. images, sounds).

This sentence confines itself to representations. It is absolutely true that representations that use any words whatsoever are non-compliant, so long as long as the reader believes that "10" is not a word and "ten" is; "Z" is not a word but "UTC" is. I think it is non-obvious that the reader will consider "10" to be a non-word, so the sentence should be reformulated. At the same time, this article is an overview of the standard and need not express thoughts in the cumbersome drawn-out way the standard does. When the standard is read as a whole, representations must not contain year names in the Chinese calendar (which I suppose means something like "year of the monkey") and representations must also not contain month names written in Roman characters; there is nothing wrong with constructing a single sentence that expresses both these restrictions.

The next sentence in the lead states

The standard organizes the dates and times so the largest temporal term (the year) is placed to the left and each successively smaller term is placed to the right of the previous term.

Strictly speaking, this only applies to representations; perhaps that should be stated. Maybe instead of "The standard organizes the dates and times" could be replaced by "In standard-compliant representations the dates and times are arranged" Jc3s5h (talk) 17:46, 17 August 2014 (UTC)

Sorry about that, "ISO/IEC Directives, Part 2" subclause 6.2.1. The title element does provide informative subject matter, primarily to distinguish itself from other ISOs, in 3 parts (for this case). Part 1, "Data elements and interchange formats", is the introductory element which helps define the the main subject. Part 2, "Information Interchange" is the main subject. Part 3, "Representation of dates and times", indicates that the standard doesn't cover every aspect of data elements and interchange formats in information exchange but just those related to representation of dates and times (e.g. interchange formats for images or data element schema for widgets are covered elsewhere). Unfortunately that applies equally to both interpretations. Scope provides normative subject matter and the particulars. If we look at the itemized list the first one it specifies is calendar date expressed as... both the definition of "calendar date" and the form expressed include "calendar month" which is this definition:

2.2.11 calendar month time interval resulting from the division of a calendar year in 12 time intervals, each with a specific name and containing a specific number of calendar days NOTE 1 A calendar month is often referred to as month. NOTE 2 See 3.2.1 for the names of the months of the calendar year in the Gregorian calendar, listed in their order of occurrence, for their number of days, and for the ordinal dates of the days in common and leap years.

This supports the subject including dates with month/day names since the notes are normative while excluding words not found in Table 1 (same logic applies for item 3 of the scope list, 2.2.8 normative note 2, and Table 2). It also does not make a requirement on the interchange of those names because clause 4 indicates what portion of table 1 is to be used for interchanging dates, ie: May = 05. JMJimmy (talk) 20:03, 17 August 2014 (UTC)

Oh, I forgot to address your last point... very much agreed your language is superior. JMJimmy (talk) 20:04, 17 August 2014 (UTC)

I agree that dates such as Friday, January 5, 1962, would be part of the subject matter of the standard. I suppose my previous example of a meeting on the last Thursday of each Gregorian calendar month could be viewed as part of the subject matter of the standard, but not representable. If one were to ask if the practice of the Vermont State Police of speaking the expiration dates of vehicle registrations over the radio as "twenty sixteen four fifteen" is part of the subject matter, no that's not part of the subject matter because it isn't expressed in characters. That said, our lead section is not obliged to confine itself to describing the scope of the standard; the lead can mention any key points that would help readers to decide if they would benefit from reading the rest of the article. Jc3s5h (talk) 21:39, 17 August 2014 (UTC)

Very true, I thought it might be good to stick with the general theme of each paragraph of the lead. p1 = generally what it is, p2 generally what it applies to (ie: in scope), p3 generally what the interchange representations are. I also wanted to preserve the spirit of what Mitch wanted in there (constraints on p1 of scope). I didn't do it very elegantly, I'll never be a great writer that's for sure. I couldn't figure out a way to say it in a similar manner to what he had without creating a WP issue so I cludged it together. The first part is fixed well enough but that Nor... is horrid with the improvements to the first half. JMJimmy (talk) 02:44, 18 August 2014 (UTC)

I propose we simply delete the sentence"

Nor does it address representations that use unspecified words (e.g. year names in the Chinese calendar) or that do not use characters (e.g. images, sounds).

because:

• Its content is covered by the last sentence of the last paragraph "Representations must be ... numerals and certain characters ... "January" or "Thursday" are not allowed in representations."
• The word "unspecified" is completely redundant. There are no "specified" words that can be used in the representation. (If you disagree, please give an example (of an 8601-compliant representation that includes a specified word.)
• The example of "year names in the Chinese calendar" is completely redundant given that we've already stated that representations are of dates in the Gregorian calendar.
• The definition implied by the link from "character" to character (symbol) is misleading - I very much doubt that 8601 intends "character" to mean "any sign or symbol".

Mitch Ames (talk) 13:21, 18 August 2014 (UTC)

I think the representations allowed in the last sentence of the last paragraph are a subset of the representations allowed by the sentence Mitch Ames wants to delete, so it can be deleted. The fact that the authors of the standard decided to exclude some representations from the scope of the standard (section 1) and decided to exclude more representations in other parts of the standard does not dictate to us how we write our lead. Jc3s5h (talk) 13:46, 18 August 2014 (UTC)

Mitch, paragraph 2 of the lead is about the scope of what it applies to not the interchange representation found in paragraph 3 of the lead. Also, 8601 does mean any sign or symbol... subject to clause 3.4 - I just didn't think it necessary to detail that clause in the lead. — Preceding unsigned comment added by JMJimmy (talk • contribs) 14:37, 18 August 2014 (UTC)

Based on the comments and the fact that the general use is digital I changed the character link to the computing page instead of the symbol one - I'm going to look into ISO 646 to see if/how that applies to the scope. JMJimmy (talk) 17:57, 18 August 2014 (UTC)