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