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.