Last modified: 2009-07-30 23:41:22 UTC
MediaWiki is currently storing the approximate time that an article is added to a category, but isn't using it or displaying it. In certain circumstances, editors could make good use of this data. While it's generally useful, there are a number of places where chronological sorting is particularly useful. These include: maintenance categories that accumulate long-standing backlogs ([[Category:Articles to be merged]]), [[WP:PROD]] (as well as most deletion procsses... see for instance the separate daily categories in [[Category:Images with unknown source]] or [[Category:Images with unknown copyright status]]). The schema documentation notes for cl_timestamp: "This isn't really used at present. Provided for an optional sorting method by approximate addition time." "Approximate" is 0-2 seconds from when it was added (based on experience comparing it to rev_timestamp). cl_timestamp was used as a central part of the [[WP:PROD]] process while the toolserver was replicating enwiki, and cl_timestamp appeared to be reliable and bug-free.
In case it's not obvious, this proposed feature has an Achilles' heel... cl_timestamp can be reset by accident or vandalism (by removing and then re-adding the category), and there's currently no way to undo the change, making it unlike almost every other feature on the wiki. While it's be possible to add the ability to undo a cl_timestamp reset, it would take a fair bit of extra work and probably require a schema change. If the "undo" bit isn't implemented, the feature is probably unsuitable for deletion processes that have a fixed schedule, and where there's more potential for misuse. But it may still be useful for other maintenance categories where the schedule isn't quite as important as it is for deletion processes. On enwiki, these tend to be the categories that don't have date-bots working on them anyway. (though even there, templates that put their transcluded articles into categories make it easy to reset a large number of cl_timestamps at once, and the only way to prevent this is to fully protect those templates, which again limits this feature's useful scope, since at least on Wikipedia, editors prefer to not fully protect templates)
*** This bug has been marked as a duplicate of bug 1289 ***
