There are cases from Aust where the BOM seems to have done a late discard of data but some compilers have left some in, with imperfections unstated. So it’s not in recent BOM files but it’s in earlier, but quite recent, compilations by others. It’s easy enough to pick up a year of missing data when shown as monthly or daily, but some annual sets look to have continuous years until you find that there is a “camouflaged” gap of a year in the middle of the data here and there. Example -

Cape Otway, aka Otway, has:

BOM 1993 vintage starting 1880
BOM 2009 web version starting 1865 but missing 1867 and a lot of 1868 and 1869
GISS homogenised starts 1901
KNMI GHCN ver2 adjusted WMO 94821 starts 1865 but has values for 1867-9 where the BOM recent does not always.

The answer as I see it is that compilers make subjective decisions on how much to in-fill and do so without much or any metadata comment. Risky.

http://hadobs.metoffice.com/hadcrut3/diagnostics/global/nh+sh/monthly

Sept 1850 is indeed missing from the crutem3 (land only) data at

http://hadobs.metoffice.com/crutem3/diagnostics/global/nh+sh/monthly

Of course it does not help that both files are named ‘monthly’!

But the complete data is available (with more sensible filenames) at
http://www.cru.uea.ac.uk/cru/data/temperature/crutem3gl.txt
http://www.cru.uea.ac.uk/cru/data/temperature/hadcrut3gl.txt
The missing number, if anyone cares, is -0.248.

.

There is another interesting feature of crutem3gl.txt that I had not noticed before. It tells us that coverage has fallen from a peak of 37% in the 1960s to 25% today.
This suggests that the number of stations used is falling, like GISS.
It is also a bit fishy, because only 30% of the Earth’s surface is land, so how can crutem cover 37%? Or does it mean only 37% of the land?
Also fishy is the fact that this decrease in coverage does not seem to show up in hadcrut3 which claims a fairly steady coverage of 80%.

Weird.

Hu,

I don’t know, maybe it is a cached version, but it would be a relatively recent cache because it goes through June, and they just updated to include the June results. Actually, it is all mystifying, because at the time I saw Steve’s post, I had the page through May loaded into an IE browser tab, where I’ve been refreshing it periodically waiting for the June update. So I went in, saved the May data to a file, refreshed, got it through June, and the line for 1850/09 was there.

But now, like you say, I’m at a different computer, in a different location, and the line is missing. So I don’t know what is going on. When I get home, on the computer where I have a copy of the June numbers with that line in it, I’ll refresh and see what happens.

Probably unrelated, I’ve noted lately that that page will not load directly into Firefox, my browser of choice, whereas it used to. Now, Firefox wants to “download” it. I don’t know if they changed something in the header structure of the file, or Firefox has changed how it handles something. It is a little irritating, though, for it not to load directly into Firefox, and have to use IE instead.

Is this it?

1850/09 -0.513 -0.427 -0.599 -0.211 -0.815 -0.463 -0.557 -0.199 -0.827 -0.195 -0.830

That’s what I’m seeing there now.

I still just see a blank line for Sept 1850 at http://hadobs.metoffice.com/crutem3/diagnostics/global/nh+sh/monthly, even after I refresh my screen. Perhaps you’re seeing a cache of an older version?

Of course, and all this information can be found online, in the same place as the flowery meadows and rainbow skies, and rivers made of chocolate, where the children danced and laughed and played with gumdrop smiles.

Are the data versioned with change orders describing the reasons for each new version?

There may be alternate explanations, such as not wanting web search engines to characterize the site by certain directories, but in this case, despite Steve’s dislike of ascribing motives, I think a lot of site owners nowadays want control of archiving and not have external groups such as archive.org engage in it for them. Whether this is legitimate or not in cases of scientific data is likely a subject of debate. A semi-legitimate example: would you want a corrupted data set that is quickly identified and corrected archived for posterity? Maybe not.

Can anyone think of a legitimate reason for blocking archiving of scientific data?