[tz] [tz-announce] 2018f release of tz code and data available

[Phake Nick]

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.

2018-10-22 05:25, Michael H Deckers via tz <tz at iana.org> wrote:

>
>     On 2018-10-21 03:00, Steve Allen wrote:
>
> > Many examples of non-normalized dates and times exist in historical
> > literature.
>
>     For time stamps of UTC, or of a time scale derived from UTC
>     with a piecewise constant offset (as for civil time scales),
>     time-of-day values on or after 24 hours may be ambiguous due
>     to leap seconds.
>
>     The fictitious UTC time stamp  "2016-12-31T25Z" could
>     indeed be taken to mean
>         2016-12-31T00Z + 25 h = 2017-01-01T00:59:59Z or else
>         2017-01-01T00Z + 01 h = 2017-01-01T00:00:00Z.
>     That is probably one reason why the draft new version
>     of ISO 8601 proposes to drop even the notation for the time
>     of day 24 h after midnight (does "2016-12-31T24Z" mean
>     2016-12-31T23:59:60Z or 2017-01-01T00:00:00Z?).
>
>     It is true that this ambiguity can arise at most for two
>     (or twelve) dates in a year, but a parser for zic input
>     has to deal with all cases, and cannot be written correctly
>     unless the notation is defined unambiguously.
>
>     There is no such ambiguity with day of the month numbers
>     less than 01 or > ultimo, so that it is always possible
>     to avoid any time-of-day values below 00 h or on or after 24 h
>     in time stamps of UTC or of civil times.
>
>     Michael Deckers.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20181022/e1cc8765/attachment.html>