Talk:ISO 8601

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
WikiProject Time (Rated B-class, Top-importance)
WikiProject iconThis article is within the scope of WikiProject Time, a collaborative effort to improve the coverage of Time on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
B This article has been rated as B-Class on the project's quality scale.
 Top  This article has been rated as Top-importance on the project's importance scale.

Wikipedia dates[edit]

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‎

Standard Date[edit]

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 (talkcontribs) 00:47, 10 November 2018 UTC (UTC)

Are the Period gaps correct[edit]

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?[edit]

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. (talk) 23:54, 3 October 2022 (UTC)Reply[reply]

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)Reply[reply]
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 202303 is ambiguous, but if the full date is included then 20230328 can be used for the basic format, whereas 2023-03-28 is used for the extended format. (talk) 20:10, 6 November 2022 (UTC)Reply[reply]
YYYY-MM (with -) is specifically allowed in § Representations with Reduced Precision. (As are YYYY for year; YYY for decade; and YY for centrury)
YYYYMM (without -) is specifically prohibited by §; 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)Reply[reply]

Local time (unqualified)[edit]

"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. (talk) 11:49, 9 January 2023 (UTC)Reply[reply]

"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.Reply[reply]
OK, thanks. Digging through some second hand sources (links below the article) confirms this. Still a shame that such standards are not publicly available... (talk) 08:56, 10 January 2023 (UTC)Reply[reply]
In contrast to IETF RFCs, many ISO standards (such as this one) are not specific to Internet usage, nor necessarily to even computing in general.

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

Local time[edit]

"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)Reply[reply]

I would write something like

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

Jc3s5h (talk) 18:21, 13 February 2023 (UTC)Reply[reply]