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

[Phake Nick]

The difference between 25:00 abd 01:00 is that, assuming the DST transition
take place at September 6 of certain year, then the last hour with DST
active would be considered as part of September 6 if 01:00 approach is
used, while it should be September 5 going to 25:00.

 2018-10-23 06:00, Stephen Colebourne <jodastephen at gmail.com> wrote:

> I'm willing to argue for a change to the Java API as there are
> definitely rules that can't be expressed in any other way except via
> out of bounds times.
>
> However, there is no particular reason for this particular rule to be
> expressed as out of bounds 25:00. In addition to Java itself, there
> are a number of other Java libraries impacted by this. As I've pointed
> out before, the rearguard approach does not really help because it is
> not a distributed set of source files - it requires pre-processing.
>
> Since there is no difference to the output timestamps, and no
> particular reason to express the rule as 25:00, can we agree to revert
> the main source file to use 01:00 until release 2020a to give time for
> the change to percolate through the libraries?
>
> thanks
> Stephen
>
>
> On Sun, 21 Oct 2018 at 00:43, Paul Eggert <eggert at cs.ucla.edu> wrote:
> >
> > Stephen Colebourne wrote:
> > > It would be much better for the upstream source to represent the data
> in a
> > > more standard and backwards compatible way.
> >
> > The original Japanese regulation does seem to say that the transition
> occurs
> > Saturday at 25:00 (as this is how such times are often expressed in
> Japan), and
> > it's better to represent data as close to the original as the format
> allows.
> > This is not a recent change to the format, which was relaxed to allow
> 25:00 (and
> > other out-of-range times) in 2007, as first proposed here:
> >
> > https://mm.icann.org/pipermail/tz/2007-May/014341.html
> >
> > with no disagreement at the time.
> >
> > > (The existing API will be supported unaltered for many years,
> potentially
> > > decades, so changing the API is not a viable solution.)
> >
> > This sort of compatibility issue is what rearguard format is for, and
> the patch
> > proposed in <https://mm.icann.org/pipermail/tz/2018-October/027032.html>
> should
> > suffice for the existing Java API, which as I understand it needs to use
> > rearguard format anyway. Success for this approach with OpenJDK has been
> > reported in <https://bugs.openjdk.java.net/browse/JDK-8212684>.
> >
> > When someone has the time, though, the Java API should get fixed, as
> insisting
> > on times in the range 00:00-24:00 prohibits useful and practical rules.
> It's not
> > just Japan; it's also rules like "22:00 on the day before the last
> Sunday in
> > March" that are quite plausible in real-world practice.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20181023/f1472204/attachment.htm>