[tz] Java & Rearguard

[Paul Eggert]

Brandon Smith wrote:

> I would say we are at a
> minimum of a year out still to get this fully adapted.

You should be OK then, as there are no plans to remove "make rearguard_tarballs" 
and I doubt whether it'll go away that quickly. Still, this shouldn't be an 
excuse for delaying for a year....


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

Not for the 1941 transition I'm talking about. In that transition, Kiev 
simultaneously (1) changed its STD-UTC offset from +03 to +01, and (2) changed 
from standard time to daylight-saving time with the usual 1-hour saving. The 
combined effect of the two simultaneous changes was to (1) switch Kiev's UTC 
offset from +03 to +02, and (2) change its tm_isdst flag from zero to positive. 
This transition has the properties you mentioned as possibly being problematic 
for your software, as it has ambiguous timestamps just before a transition from 
non-DST to DST.

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

That email was talking about something different: a negative SAVE value in a 
Rule line. That's a different way to cause the kind of transition that you 
mentioned might cause a problem for your software.