Have you configured a local timezone offset? day UTC is day-1 22:00:00 in your timezone.

dasch wrote:

I had a local time offset, but now it's of and the problem still remains

dasch wrote:

okay, well workaround is not that complicated, but the behaviour is really strange

Created attachment 5704
Patch to have #time parse dates without an explicit timezone in the target time zone rather than the arbitrary PHP default

attachment x3.diff ignored as obsolete

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.

Created attachment 8183
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.

Attached:

sumanah wrote:

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.

PHP 5.1 has pretty much fallen out of support for us.

(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.

(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.