<div dir="auto"><div><div dir="auto"><br></div><div dir="auto">I can't see the problem here. For instance, Japan is now using UTC+9, so the leap second take place right before 9am(00:00:00Z), yet 10am that day would still unambiguously mean 10am(01:00:00Z). I cannot see why it would be a problem for UTC after 24z.</div><br><div class="gmail_quote"><div dir="ltr">2018-10-22 05:25, Michael H Deckers via tz <<a href="mailto:tz@iana.org">tz@iana.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On 2018-10-21 03:00, Steve Allen wrote:<br>
<br>
> Many examples of non-normalized dates and times exist in historical<br>
> literature.<br>
<br>
For time stamps of UTC, or of a time scale derived from UTC<br>
with a piecewise constant offset (as for civil time scales),<br>
time-of-day values on or after 24 hours may be ambiguous due<br>
to leap seconds.<br>
<br>
The fictitious UTC time stamp "2016-12-31T25Z" could<br>
indeed be taken to mean<br>
2016-12-31T00Z + 25 h = 2017-01-01T00:59:59Z or else<br>
2017-01-01T00Z + 01 h = 2017-01-01T00:00:00Z.<br>
That is probably one reason why the draft new version<br>
of ISO 8601 proposes to drop even the notation for the time<br>
of day 24 h after midnight (does "2016-12-31T24Z" mean<br>
2016-12-31T23:59:60Z or 2017-01-01T00:00:00Z?).<br>
<br>
It is true that this ambiguity can arise at most for two<br>
(or twelve) dates in a year, but a parser for zic input<br>
has to deal with all cases, and cannot be written correctly<br>
unless the notation is defined unambiguously.<br>
<br>
There is no such ambiguity with day of the month numbers<br>
less than 01 or > ultimo, so that it is always possible<br>
to avoid any time-of-day values below 00 h or on or after 24 h<br>
in time stamps of UTC or of civil times.<br>
<br>
Michael Deckers.<br>
<br>
</blockquote></div></div></div>