Removing systemv, pacificnew, Rule TYPEs, zic -y
I noticed recently that the systemv file, which adapted a subset of North American zones with limited rulesets to old versions of System V, has had all its once-useful bits commented out since 2005p. Looking back at list archives, even discussion at the time argued that the file wasn't really needed then. The attached proposed patch 0001 removes this obsolete file and its references. Of course, I was only looking at systemv in the first place because I'd also recalled that we're still distributing the pacificnew file, which has caused some confusion every so often and has likewise generally outlived its usefulness. This led me to the related file yearistype.sh, which is also unused, except as a default script to pass to the Makefile to process the TYPE field of Rule lines. Given that the TYPE field hasn't been used by tzdata since 2000f and has been more formally deprecated since 2015f, the whole unused feature is ripe for "spring cleaning". The attached proposed patch 0002 completely drops support for the TYPE field (marking it reserved for compatibility purposes) and causes non-trivial use of the field or use of zic's -y option to error (instead of warning as it has since 2017c). It also removes the pacificnew and yearistype.sh files that are no longer needed and updates documentation accordingly. I don't presently foresee any need to repurpose the nullified field down the road, but this is the next step in allowing us to "reclaim" it in the event that such a need should arise in the future. -- Tim Parenti
Since we need a new release soon for the changes to Casey, which took effect about 7 hours ago, I've rebased and applied these patches to the development repository. Updated versions attached. -- Tim Parenti On Wed, 13 May 2020 at 21:54, Tim Parenti <tim@timtimeonline.com> wrote:
I noticed recently that the systemv file, which adapted a subset of North American zones with limited rulesets to old versions of System V, has had all its once-useful bits commented out since 2005p. Looking back at list archives, even discussion at the time argued that the file wasn't really needed then. The attached proposed patch 0001 removes this obsolete file and its references.
Of course, I was only looking at systemv in the first place because I'd also recalled that we're still distributing the pacificnew file, which has caused some confusion every so often and has likewise generally outlived its usefulness. This led me to the related file yearistype.sh, which is also unused, except as a default script to pass to the Makefile to process the TYPE field of Rule lines.
Given that the TYPE field hasn't been used by tzdata since 2000f and has been more formally deprecated since 2015f, the whole unused feature is ripe for "spring cleaning". The attached proposed patch 0002 completely drops support for the TYPE field (marking it reserved for compatibility purposes) and causes non-trivial use of the field or use of zic's -y option to error (instead of warning as it has since 2017c). It also removes the pacificnew and yearistype.sh files that are no longer needed and updates documentation accordingly.
I don't presently foresee any need to repurpose the nullified field down the road, but this is the next step in allowing us to "reclaim" it in the event that such a need should arise in the future.
-- Tim Parenti
On 2020-05-14 01:54, Tim Parenti wrote:
I noticed recently that the systemv file, which adapted a subset of North American zones with limited rulesets to old versions of System V, has had all its once-useful bits commented out since 2005p. Looking back at list archives, even discussion at the time argued that the file wasn't really needed then. The attached proposed patch 0001 removes this obsolete file and its references.
Thanks! But if you do that you must also modify the goal of tzdb as stated in the theory file: that the tzdb data "record the history and predicted future of all computer-based clocks that track civil time." SystemV clocks have been "computer-based clocks that track civil time", and they are no longer "recorded". So, apparently, you no longer want to record facts about "all computer-based clocks" tracking civil time. Actually, with very few exceptions, tzdb currently records the current state, the predicted future, and a selected part of the history, of civil time scales (not of computer clocks) as far as they are known; for the use in computer clocks, with special support for POSIX computer clocks. The dst bit is a special attribute for POSIX, while other attributes required by other computer systems (eg, the offset to standard time and the summer time indicator) are currently not supported by tzdb. Michael Deckers.
On 10/4/20 12:30 PM, Michael H Deckers via tz wrote:
SystemV clocks have been "computer-based clocks that track civil time", and they are no longer "recorded".
There is a bit of a second-order effect here, since SystemV clocks were never intended to track civil time for the long haul; they were intended only to track it during a single period when the authorities did not change the rules, and when rules used the Gregorian calendar in one of a few stereotyped ways. You're right that in some sense a SystemV data entry establishes a new kind of "civil time", but that's only in the sense that tzdb's Europe/Amsterdam establishes a new kind of "civil time" that differs in minor ways from civil time actually observed in Amsterdam long ago (due to deficiencies in tzdb).
Actually, with very few exceptions, tzdb currently records the current state, the predicted future, and a selected part of the history, of civil time scales (not of computer clocks)
That's a better way to put it, yes. I installed the attached proposed patch to do something briefly along those lines. There's no need for more discussion at that point since this is an intro sentence and the details are explained later anyway.
The dst bit is a special attribute for POSIX, while other attributes required by other computer systems (eg, the offset to standard time and the summer time indicator) are currently not supported by tzdb.
I wouldn't go that far; .zi files contain info supporting offset to standard time and a "summer time indicator" (though I don't know how exactly that would differ from POSIX's tm_isdst). To some extent this part of tzdb is arbitrary anyway, as it's not entirely clear what is meant by that stuff and hardly anybody cares about it anyway. Right now, tzdb surely disagrees with Yukon law in this area but Yukon's clocks are right and nobody has complained here.
participants (3)
-
Michael H Deckers -
Paul Eggert -
Tim Parenti