How long will the rearguard formats continue be provided?
Hello! Our team utilizes a custom version of tzcode and a calendar utility that don't support negative DST offsets that was brought back in 2018e nor the 2018f fallback transactions Japan rules that were at 25:00 hour. We utilized 2018i rearguard-format version and we were able to utilize 2018i with our parsers. The 2018i announcement mentions that the rearguard is intended to be a temporary transition aid; that raises fear if we have to patch one of the upcoming tzdata releases that don't provide a rearguard with similar fixes. While we are planning to work on fixes for our timezone parsers; in order to ensure we have enough leeway for our new solutions, we would be curious to know how long will these rearguard versions (with no negative offsets) continue to be provided?
On 1/23/19 2:40 PM, Pramoth Murali wrote:
how long will these rearguard versions (with no negative offsets) continue to be provided?
There is no definite schedule for that, just as there is no definite schedule for anything associated with tzdb. It's a volunteer effort, after all. That being said, you needn't retrieve a rearguard-format tarball to get rearguard-format data. You can instead use the ordinary tarball, which comes bundled with software that will generate rearguard format upon request. Even if I stop my informal distribution of a rearguard-format tarball, you can still generate rearguard-format data from the standard distribution by running the command 'make rearguard.zi'. I also suggest boosting the priority of updating your custom version of tzcode so that it works the way ordinary tzcode works. tzcode's zic has supported negative offsets for decades, and it's time to catch up.
There will be major implementations using the rearguard format into the indefinite future; billions more instances of OSs will use rearguard than use non-rearguard. The non-rearguard causes significant compatibility problems, and doesn't provide any additional functionality that would offset those problems. Mark On Thu, Jan 24, 2019 at 3:32 AM Paul Eggert <eggert@cs.ucla.edu> wrote:
On 1/23/19 2:40 PM, Pramoth Murali wrote:
how long will these rearguard versions (with no negative offsets) continue to be provided?
There is no definite schedule for that, just as there is no definite schedule for anything associated with tzdb. It's a volunteer effort, after all.
That being said, you needn't retrieve a rearguard-format tarball to get rearguard-format data. You can instead use the ordinary tarball, which comes bundled with software that will generate rearguard format upon request. Even if I stop my informal distribution of a rearguard-format tarball, you can still generate rearguard-format data from the standard distribution by running the command 'make rearguard.zi'.
I also suggest boosting the priority of updating your custom version of tzcode so that it works the way ordinary tzcode works. tzcode's zic has supported negative offsets for decades, and it's time to catch up.
Mark Davis ☕️ wrote:
There will be major implementations using the rearguard format into the indefinite future
That's fine. We don't distribute the binary data either, even though billions of computers use that data and the binary data files are portable. Downstream users can run 'make' (or whatever) to generate the binary data, and they can run 'make' (or whatever) to generate rearguard data too.
On 2019-01-25 12:10, Paul Eggert wrote:
Mark Davis ☕️ wrote:
There will be major implementations using the rearguard format into the indefinite future That's fine. We don't distribute the binary data either, even though billions of computers use that data and the binary data files are portable. Downstream users can run 'make' (or whatever) to generate the binary data, and they can run 'make' (or whatever) to generate rearguard data too.
Most OSes and distros run or port zic to build the standard data and most OS libraries use that data. Other platforms which don't use zic or tzdb data, or update their tools to be consistent, may fall behind, use may diminish, and support may be dropped, encouraging other projects to drop the platform. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised.
participants (4)
-
Brian Inglis -
Mark Davis ☕️ -
Paul Eggert -
Pramoth Murali