I don’t have time to find the reference right now (if I even can), but even most of the authors of ISO 8601 consider it an egregious error to permit "24:00" as a representation of midnight. The Library of Congress specification should profile this use out. (And "23:59:60", and "23:60", too, except for leap seconds; more below.)
Allowing these values causes serious headaches for implementation (particularly for temporal arithmetic), and not only adds nothing to the expressive power of the system, they make the system at least more confusing, it not outright ambiguous.
The easiest way (I know of) to explain this is to point out that there are 24 hours in a day, and they are numbered "00" through "23". If you permit a "24", the default implication is that there are 25 hours in a day, numbered "00" through "24". (I often wonder if this issue would come up if we had started off numbering the hours "01" through "24".)
The first minute of Tuesday is "00:00"; the last minute of Monday is "23:59". They are not the same. The first second of Tuesday is "00:00:00"; the last second of Monday is "23:59:59". They are not the same. The first microsecond of Tuesday is "00:00:00.000"; the last microsecond of Monday is "23:59:59.999". They are not the same. Etc.
In the table feature #215 lists T01:60:00 = T01:59:60 = T02:00:00, and is attributed to ISO 8601. This, AFAIK, is simply incorrect. ISO 8601:2004 says that a “minute is represented by two digits from [00] to [59]” and that a “second is represented by two digits from [00] to [60]. The representation of the second by [60] is only allowed to indicate a positive leap second or an instant within that second”. Permitting a minute to be represented by "60" is exactly as bad as permitting an hour to be represented by "24", and should most definitely not be permitted by the LOC extended date format.
But permitting a second that is not a leap second to be represented by "60" is even worse. If this were the case one would have no way to differentiate the last second of a day with a leap second (e.g., XXXX-06-30T23:59:60) from the first second of the next day (e.g., correctly represented by XXXX-07-01T00:00:00, but if feature #215 were followed, possibly represented by XXXX-06-30T23:59:60). I.e., with #215 I could’t tell what "XXXX-06-30T23:59:60" means unless I know whether or not IERS determined that there would be a mid-year leap second in XXXX. I, for one, don’t even know how to find out, let alone write a program that can know. (Although I suppose looking in wikipedia is a good start :-)
|