re: #104 Charles

Another point — bugs get fixed because they get noticed.

Bugs that don’t get noticed can live on in code for a long time, before the particular combination of events that triggers a problem result, and gets them noticed.

The fact that bugs existed in the code is absolutely NOT proof that any inaccurate data was produced or used in any situation. These bugs may not have caused any ill effects — because if they had, the chances are that the scientists who used the program would have noticed, and then the bug would have been fixed.

We are talking about live data, and bugs that created live data, inaccurate live data.

“I am very sorry to report that the rest of the databases seem to be in nearly as poor a state as Australia was. There are hundreds if not thousands of pairs of dummy stations, one with no WMO and one with, usually overlapping and with the same station name and very similar coordinates. I know it could be old and new stations, but why such large overlaps if that’s the case? Aarrggghhh!”

“So.. should I really go to town (again) and allow the Master database to be ‘fixed’ by this program? Quite honestly I don’t have time - but it just shows the state our data holdings have drifted into. Who added those two series together? When? Why? Untraceable, except anecdotally. It’s the same story for many other Russian stations, unfortunately - meaning that (probably) there was a full Russian update that did no data integrity checking at all. I just hope it’s restricted to Russia!!”

Ian Harris was put in charge of live legacy programs and data, and his 314 page narrative is a chronological diary of what he encountered with these programs and data.

This data did get into the scientific community, one example as noted above in the section about the CRU TS 3.0 database.