Last modified: 2014-09-14 07:18:23 UTC
For instance one of the first wikis in the URL, wikitau, is currently down and IA last crawled it in May: http://web.archive.org/web/20120422190918/http://www.wikitau.org/index.php5/Accueil But wikistats says that the information was last updated 13h ago. There's little use in knowing when it was last attempted to update the data; if the column actually contained the "last update" date, it would be useful. In the future, it might also help identifying dead wikis, wikis with permanent problems, wikis to attempt updates for less often, etc.
Same for errors 991 due to lag, for instance http://wikicafe.metacafe.com/en/api.php?action=query&meta=siteinfo&maxlag=5 <error code="maxlag" info="Waiting for a database server: 14 seconds lagged"> (wikicafe is probably never not lagged, so my random click was particularly unlucky).
you know, that actually happens on the database level. the column for timestamp uses 'on update CURRENT_TIMESTAMP', so every time something is being touched, it also updates the timestamp. and in cases where fetching fails, there is also something to update, the http return code, which then also triggers the ts. | ts | timestamp | NO | | 0000-00-00 00:00:00 | on update CURRENT_TIMESTAMP |
Created attachment 16464 [details] 800 alive wikis currently erroring out on wikistats (In reply to Daniel Zahn from comment #2) > you know, that actually happens on the database level. I don't challenge the technical correctness, but the timestamp can get quite useless for presentation to the users. If that's fine enough, maybe the focus should be instead on reducing such errors. I run checkalive.py and out of 3159 rows with error 991 or higher there are at least 800 which actually seem alive, whose URLs I attach.
