Ambiguous time represenation
Closed this issue · 3 comments
ISO8601 allows removal of T before the time only when the result is not ambiguous with a date.
| format | invalid example | ambiguous with |
|---|---|---|
%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?
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.