Last modified: 2013-06-18 15:49:56 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 17080 - #time parserfunction parses dates in the PHP default timezone before converting to UTC
#time parserfunction parses dates in the PHP default timezone before converti...
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
ParserFunctions (Other open bugs)
unspecified
All All
: Low normal (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-19 17:01 UTC by DaSch
Modified: 2013-06-18 15:49 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Patch to have #time parse dates without an explicit timezone in the target time zone rather than the arbitrary PHP default (2.70 KB, patch)
2009-01-19 17:59 UTC, Brad Jorsch
Details
Patch to fix {{#time}} for systems without the DateTime class. (1.24 KB, patch)
2011-02-20 20:37 UTC, Brad Jorsch
Details

Description DaSch 2009-01-19 17:01:42 UTC
When using the #time function the dates I get are all a day behind

look for example here http://www.wecowi.de/view/WeCoWi:time-parser_bug
Comment 1 Niklas Laxström 2009-01-19 17:09:39 UTC
Have you configured a local timezone offset? day UTC is day-1 22:00:00 in your timezone.
Comment 2 DaSch 2009-01-19 17:26:55 UTC
I had a local time offset, but now it's of and the problem still remains
Comment 3 DaSch 2009-01-19 17:53:30 UTC
okay, well workaround is not that complicated, but the behaviour is really strange
Comment 4 Brad Jorsch 2009-01-19 17:59:10 UTC
Created attachment 5704 [details]
Patch to have #time parse dates without an explicit timezone in the target time zone rather than the arbitrary PHP default
Comment 5 Brad Jorsch 2009-01-19 17:59:27 UTC
The issue is that #time parses dates without an explicitly specified timezone in the PHP default timezone and then converts that to UTC. If the PHP default timezone happens to be UTC, all is good. If the PHP default is east of UTC, we get this obvious problem, and if it is west of UTC we get problems in less obvious cases.

For example, {{#time:Y-m-d|2009-01-01}} parses the date at midnight in the PHP default timezone, which might result in DateTime object containing the time "2009-01-01T00:00:00+01:00". #time then converts this to UTC, resulting in "2008-12-31T23:00:00+00:00", giving "2008-12-31" rather than the expected "2009-01-01" as the output.

It would probably make more sense to have #time use UTC as the default, and #timel the $wgLocaltimezone time. This can be done easily by specifying the second parameter to DateTime::__construct for the modern PHP case, and setting TZ before the strtotime() (instead of only for the date() call) should suffice for the fallback case.
Comment 6 Brad Jorsch 2011-02-20 20:37:42 UTC
Created attachment 8183 [details]
Patch to fix {{#time}} for systems without the DateTime class.

A patch almost identical to the first section of my patch was applied in r50506 and r60826 to fix a different bug, so this is half-fixed now.

The bug still exists on systems without the PHP DateTime class (e.g. PHP before 5.2), and in fact is even more broken since r60825 effectively disabled use of the TZ environment variable. If we don't care about 5.1 anymore I suppose this bug can be closed (and the non-DateTime codepath removed), otherwise I've attached an updated patch.
Comment 7 Sumana Harihareswara 2011-11-14 16:44:57 UTC
Sorry for the wait, Brad.  Marking this bug with "need-review" to make sure developers see that your patch awaits review.  Thanks for the contribution.
Comment 8 Aaron Schulz 2012-04-13 03:54:00 UTC
PHP 5.1 has pretty much fallen out of support for us.
Comment 9 Brad Jorsch 2012-04-13 13:19:59 UTC
(In reply to comment #8)
> PHP 5.1 has pretty much fallen out of support for us.

Removing the pre-5.2 code path entirely would be an acceptable fix as far as I'm concerned.
Comment 10 Max Semenik 2012-04-26 19:39:51 UTC
(In reply to comment #9)
> (In reply to comment #8)
> > PHP 5.1 has pretty much fallen out of support for us.
> 
> Removing the pre-5.2 code path entirely would be an acceptable fix as far as
> I'm concerned.

This was done some time ago, closing the bug.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links