From [[mw:Help:Extension:ParserFunctions]], "c" is defined as:

ISO 8601 formatted date, equivalent to Y-m-dTH:i:s+00:00.

Since the timezone is specified for "c", you are seeing the correct output.

Of course, http://php.net/strftime says that "%c" is

Preferred date and time stamp based on local[e]

And the Linux manpage for strftime (http://linux.die.net/man/3/strftime) says:

The preferred date and time representation for the current locale.

Berkely manpages (http://compute.cnr.berkeley.edu/cgi-bin/man-cgi?strftime+3) offers a little more information:

Locale's appropriate date and time represented as:

%a %b %d %H:%M:%S %Y

This is the defaut behavior as  well  as  standard-
conforming  behavior  for standards first supported
by releases prior to Solaris 2.4. See standards(5).

So, yes, the mw implementation appears to be wrong.

hmm, whats a non-hacky way of fixing this. The obvious way is to pass some sort of timezone offset as third parameter to sprintfDate, and then cut off the last 5 characters of gmdate( 'c', $unix ) and replace it with the time zone offset. But that's icky... I guess should construct 'c' from its constituent parts...

If we do fix this we should consider adding a new formatting character to get the timezone offset (+05:00) and timezone name (MST, ADT, etc). There's probably certain circumstances where that would be useful

Furthermore, {{#timel:o-W}} produces 2012-52 (wrong)

There was a bug in the code where 'o' had the timezone adjusted twice (So it was 18 hours ahead, instead of 9 hours - thus putting it in 2012 when it still should of been in 2011). None of the other formatting characters had this issue. This should be fixed as of r107806 (of course we won't see the issue again until next new years)

I think adding a timezone parameter to Language::sprintfDate() is the appropriate way to go about it. Then instead of gmdate(), we could use "new DateTime()", which accepts a timezone parameter, and the format() method to format it. The "c" format specifier in PHP does support timezones other than UTC, if it's called in the correct way.

I also note that {{#timel:}} returns the wrong thing for 'r' and 'U'.

Gerrit change 55274 to core adds the parameter to Language::sprintfDate()
Gerrit change 55275 uses this parameter in ParserFunctions.
Gerrit change 55276 uses this parameter in Scribunto.

https://gerrit.wikimedia.org/r/55274 (Gerrit Change Iea1f78428bc0d32d6395818311dbe4b94d776c42) | change APPROVED and MERGED [by jenkins-bot]

Not sure this is working as intended, but hard to tell because the documentation on it is very slim. See http://www.mediawiki.org/wiki/User:Technical_13/SandBox for what I expected it to output. Basically, I expected it to output the local timezone and not the server or UTC... It is currently only outputting UTC and I see no benefit to that.

(In reply to comment #6)

Not sure this is working as intended, but hard to tell because the
documentation on it is very slim. See
http://www.mediawiki.org/wiki/User:Technical_13/SandBox for what I expected
it
to output. Basically, I expected it to output the local timezone and not the
server or UTC... It is currently only outputting UTC and I see no benefit to
that.

Yeah sorry, we have multiple definitions of "local" timezone. Timel outputs the server time where time always outputs utc. Most wikimedia projects (including mw.org) use utc as server time. Some exceptions are korean, and german. Basically timel outputs the same timezone as what ~~~~~ outputs.

Change 95390 had a related patch set uploaded by MarkAHershberger:
Add timezone support to mw.lang:formatDate

https://gerrit.wikimedia.org/r/95390

Change 95390 merged by MarkAHershberger:
Add timezone support to mw.lang:formatDate

https://gerrit.wikimedia.org/r/95390

No open patches to review here (backport patch for REL_1_21 got merged), hence restting status to RESOLVED FIXED.