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

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 202501 is ambiguous, but if the full date is included then 20250112 can be used for the basic format, whereas 2025-01-12 is used for the extended format. 98.31.29.4 (talk) 20:10, 6 November 2022 (UTC)

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

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

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

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

Local time (unqualified)

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

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

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

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

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

Local time

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

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

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