[tz] Java & Rearguard

[Brandon Smith]

Paul Eggert wrote:
>
> >> There's no intent to remove rearguard format in the next release. You'll still
> >> be able to get rearguard format by running "make rearguard_tarballs", a command
> >> that should run automatically if you have the right tools: basically a POSIX
> >> environment and some freely-available portable programs like GNU tar.

Understand this perspective.  I thought the proposal was to completely
remove this ability.  From time to time we have been required to act a
bit more efficiently than our normal cadence due to political changes
(e.g. Brazil), so we have been leveraging this in the interim.

>
> >> What have been the obstacles, and what progress has been made so far? That is,
> >> the problem has been publicized widely for well over a year; what's the rough
> >> timeframe for your company's process for adapting to negative offsets?

Unfortunately, I cannot answers this as thorough as I would like.  We
first discovered this last year when Brazil was going through it's
period of uncertainty regarding when they would have DST, I think
around October 2018.  With the decisions falling through there, this
was not further prioritized as it should have been due to things I
personally cannot control.  To remain current thereafter, rearguard
was chosen as the short term resolution.

I don't think the full scope of impact and adoption is clear yet.  The
parsing works fine as far as I know, it's more the application
behaviors downstream.  One example being the ambiguous problem stated
where that has been a longstanding notion that the ambiguous local
time period always happened during the transition from DST off to DST
on for a given timezone, which appears to be new with these changes
(see below).  I imagine there are going to be more findings with time,
but I'm not sure of the full scope currently  Fully understand the
perspective that this is not this communities problem.  Given the
typical rate at which this company moves I would say we are at a
minimum of a year out still to get this fully adapted.  To answer your
question, little progress has been made thus far, I'm trying to fix
that.

It sounds like this is a change that we are going to have to figure
out how to account for and is clearly something I need to understand
better.  My desire in the meantime is to continue to have something
even if I have to generate it (i.e. rearguard), that can help us get
by until we figure this all out.

>
> >> For what it's worth, this particular situation is not new in tzdata. For
> >> example, Europe/Kiev has a transition from +03 (without DST) to +02 (with DST)
> >> on 1941-09-19 at 24:00, which means that timestamps that day between 23:00 and
> >> 24:00 are ambiguous in Kiev. This transition has been present since the release
> >> of tzdata 1999j two decades ago. I'm sure there are other examples.

Maybe I'm just missing it but as far as I can tell Europe/Kiev is
implemented as a positive offset still such that the Summer Time (i.e.
+03) would still have DST on and the DST off period would be +02.
This is the use case we are used to.  This would align to a statement
made when Ireland rules were first introduced suggesting this was the
first implementation of negative offsets in tzdata
(https://mm.icann.org/pipermail/tz/2018-January/025876.html).