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 ***