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

[Stephen Colebourne]

The java.time.* code exposes the local time that the transition occurs.
This can be represented within the bounds 00:00 to 24:00. There is no way
to represent 25:00 or negatives.
https://docs.oracle.com/javase/8/docs/api/java/time/zone/ZoneOffsetTransitionRule.html

As such, the tzdb parser would have to convert 25:00 and try to reinterpret
it as the next day within the valid bounds, which is far from ideal. It
would be much better for the upstream source to represent the data in a
more standard and backwards compatible way.

(The existing API will be supported unaltered for many years, potentially
decades, so changing the API is not a viable solution.)

Stephen


On Thu, 18 Oct 2018, 19:15 Paul Eggert, <eggert at cs.ucla.edu> wrote:

> On 10/18/18 8:14 AM, Christos Zoulas wrote:
> > My folks are reporting that java does not like it:
> >
> > ERROR: Failed: java.lang.Exception: Failed while parsing file
> > '/tmp/tz.tmp_2/asia' on line 1655 'Rule       Japan   1948    1951    -
>      SepSat>=8 25:00 0       S'
> > ERROR: java.lang.Exception: Failed while parsing file
> > '/tmp/tz.tmp_2/asia' on line 1655 'Rule       Japan   1948    1951    -
>      Sep     Sat>=8 25:00    0       S'
> >
> Thanks for the heads-up; please try the attached patch.
>
> Is there some way your folks can try the development version on GitHub
> every now and then? That "25:00" has been in the development version
> since last month and was explicitly called out when the patch was
> circulated on the mailing list
> <https://mm.icann.org/pipermail/tz/2018-September/026891.html>. It'd
> have been nice to catch the glitch before 2018f came out.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20181020/46b211bc/attachment-0001.html>