This would make something like {{#time:H:i:s| 9:30 January 1, 2012 MST}} convert the time from 9:30 mountatin standard time to whatever it is in UTC.
I made one minor change from the patch on bugzilla in changing an @ to a wfSuppressWarnings. (The @ was already in the code, it wasn't introduced by the patch).
* When using HipHop, is_callable() returns false for objects which have only a __call() method instead of the requested one.
* Work around this by removing the ParserFunctions_HookStub hack.
* To retain the behavior that the code of ParserFunctions_body.php is only loaded when needed, turn it into a static class.
* Defer the registering of the ParserClearState hook until a relevant function is called.
* Use autoloader for ConvertParser, and ExprParser which the code was cloned from
* Fix PHP 5.1 compatibility, while there's no requirement for us to keep it, there's also no need to break it unnecessarily, and it's a really trivial fix in this case.
* Tidy whitespace
* Use ConvertDimension::getLocalisedName() for the dimensionmismatch error, as intended
[[Template:Convert]] on enwiki is a behemoth of a construction that just about manages to do this sort of conversion, taking {{convert|5|mi|km}} and outputting "5 miles (8 km)", etc. To port this to another wiki requires copying over three and a half thousand subtemplates. The additional load produced by including numerous copies of this template is measurable on large pages on enwiki, and it eats voraciously into the template limits.
This revision introduces {{#convert: 5 mi | km }}, outputting "8 km" or thereabouts. See http://www.mediawiki.org/wiki/User:Happy-melon/Convert for more details, or look at the examples in the parser tests.
In a very rough profile, comparing 50 calls to {{convert}} verses the same 50 calls to the wrapper template shown at the link above, the parser function implementation reduces page load time by 72%, preprocessor node count by 83%, post-expand include size by 86% and template argument size by 97%. More detailed profiling would probably reveal places where extra caching could improve performance further.
The primary reason for putting it in ParserFunctions instead of its own extension is availability: PFs are already available across the cluster, and it's accepted as an essential extension for any wiki wishing to emulate or mirror WMF content. One less separate extension installed on the cluster is one less extension which has to be matched by reusers.
It's still missing a lot of units, which I ran out of patience to copy from {{convert}}; I thought I'd get some feedback on the infrastructure first.
After discussion with Tim. The back-compat stuff here seems pretty
useless -- why can't people with old versions of MediaWiki just keep the
old feature sets, and upgrade MediaWiki to get new features for
extensions? We branch extensions for a reason.
Bug 19093. Previously {{#switch:foo|bar|#default=baz}} would behave
differently from {{#switch:foo|#default|bar=baz}}, even though they'd
behave identically if "#default" was replaced by "foo".
I changed switchObj but not switchHook. In testing, switchObj was the
only method that seemed to be used, and I didn't want to make untested
changes to switchHook, so if that's used, the behavior may remain in
some cases. It seems like code is duplicated between them -- whatever
the difference is, that should probably be factored out.
This passes all existing parser tests for #switch, of which there are
none, so don't blame me if it breaks something. ;)
* Defer loading the bulk of the code until a parser function is actually called. Necessary due to the recent large increase in code size.
* Fixed the total disregard for parser state and object-oriented data flow in ExtParserFunctions::loadRegex().
