Talk:ISO 8601

Wikipedia dates

Some people have proposed using ISO 8601 for Wikipedia dates. For more of this discussion, see Wikipedia talk:Manual of Style (dates and numbers).

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

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

-- (unsigned) 2014-02-11T22:05:46‎ 67.52.192.26

Standard Date

You can use quite a couple templates, in the YYYY-MM-DD date format

{{date|2=ISO}} or {{ISO date}} could be used. — Preceding unsigned comment added by 98.31.29.4 (talk • contribs) 00:47, 10 November 2018 UTC (UTC)

Are the Period gaps correct

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

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

Is this really correct?

I might be missing something, but surely 2003-02-15/P2M -> 2003-04-15. Where does 2004-03-15 come from? (which is 13 months ahead) Likewise for the 2nd statement

When the day of the month is omitted

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

A single date (1906 August 4)

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

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

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

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

Limitations / Criticism

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

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

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

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

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

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

Too much format flexibility

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

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

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

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

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

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

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

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

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

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

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

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

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

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