<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>