The ISO format is based on numerical dates. Thus for the example it would
be 2003-06-24. It includes hyphens and has leading zeros for days and
months. To the extent that I have been applying them I would enter such a
date as []-[[06-24]]. The first hyphen is outside of the link, and I
have written redirects for the numerical dates on an as required basis.
I didn't bother putting that one in because there didn't seem to be much
support for it on the voting page. I can put it in if you want. It will be
infinitesimally slower than the rest due to the need for month name->number
It seems a little bats that at a time when our
databse is struggling,
we're adding more load to the system for something so trivial.
This should not add substantial load if properly coded, since it's just a
search/replace operation with a fairly specific match (only triggers on
That's my thinking too, although I haven't tested it. There's no extra DB
access, which by far forms the lion's share of the time required to display
a page. CPU load is about 5-6 lightweight preg_replace calls. They all match
a limited number of characters, and start with "[[". I thought long and hard
about various possible implementations: say, a single more complex regex
plus some PHP code to distinguish between the various cases, but I decided
that would take longer. Ditto for somehow incorporating it into
replaceInternalLinks(). The only faster thing way I can think of is writing
it in C. Setting up the regular expressions from the month name array is
done once per script run (stored in static variables), so if a tight loop of
addWikiText calls is slow, it won't be my fault.
It will help us present a consistent picture throughout
our pages while not giving up some editorial liberty. I therefore fully
support the implementation of this feature, unless the code is completely
Yes, well you'll be able to judge that for yourself soon if I stop typing
emails and start doing some real work. :)
-- Tim Starling.
Hot chart ringtones and polyphonics. Go to