Talk:ISO 8601
This is the talk page for discussing improvements to the ISO 8601 article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
Archives: Index, 1, 2, 3Auto-archiving period: 60 days |
Time B‑class Top‑importance | ||||||||||
|
Text and/or other creative content from ISO 8601 usage was copied or moved into ISO 8601 with this edit. The former page's history now serves to provide attribution for that content in the latter page, and it must not be deleted as long as the latter page exists. |
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, never24: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)