Closed robinpokorny closed 2 years ago
By my reading of the standard context can disambiguate the representations.
So, if your application is explicitly communicating dates, or explicitly transmitting times then there's no chance of confusion.
The table has section headers to clarify the representations being shown so I think there's no confusion here.
However I could add another clarifying note above the table to help inform of this potential issue.
Yes, it's context-dependent, true.
I think a warning on top is probably the best solution now.
Note to self:
%h
, %h%m
, and %h%m%s
formats are all explicitly included as valid examples in Annex A in Table A.9.
ISO8601 allows removal of
T
before the time only when the result is not ambiguous with a date.%h
20
%C
%h%m
2021
%Y
%h%m%s
110201
2011-02-01
I understand that the last invalid example is not a valid date under the standard, yet it feels that it could cause confusion anyway.
Should there be an asterisk with these formats to show this danger?