[tz] Proposed reversions, for moving forward

Eliot Lear lear at cisco.com
Fri Aug 8 09:35:10 UTC 2014

Hash: SHA1

Just for my own edification, it seems to me that there are some simple
rules to follow.  Let me know if I'm even close:

1.  If the data is correct, there is no issue.
2.  If the data is known to be false, it should come out.
3.  If the data has no basis in fact (e.g., not known to be false but
also no basis to believe it is true), it should come out.
4.  If the data has conflicting historical viewpoints, it is a judgment
call based on the quality of the reports.

Does that seem about right or did I get something wrong or miss something?

To me, stability of false or seemingly fabricated information (2 & 3) is
actually a bad thing because people cite the database in their works and
we don't want to perpetuate that.


On 8/8/14, 8:25 AM, Alan Barrett wrote:
> On Thu, 07 Aug 2014, Paul Eggert wrote:
>> Although we didn't make the changes lightly, we valued correctness
over stability even when we knew we didn't achieve 100% correctness. 
This has long been common practice in tz maintenance.
> Yes, valuing correctness over stability is good, even when the new
data is not 100% correct, provided it is more correct than the old data.
> The stability-related complaints have been about cases where the "more
correct than the old data" condition was not perceived to be satisfied.
> I am gradually coming round to the opinion that the new data is
probably more correct than the old data, but that is not clear to all
> --apb (Alan Barrett)

Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/


More information about the tz mailing list