mysql2date adding timezone offset when given GMT time

[lisota]

Recent changes to mysql2date seem to have introduced a timezone bug offset.

I am seeing this in lastbuilddate in RSS feeds which uses get_feed_build_date(). get_feed_build_date() retrieves a set of modified times from the database in GMT format.

Then it sends the latest one to mysql2date for formatting with 'r' as the chosen format. mysql2date is adding a timezone offset with the wp_timezone() function.

The result in the RSS feed is a GMT time with an incorrect timezone offset (should be +0), based on the timezone set in WP admin.

In our case, our WP timezone is -8. RSS validation fails because the lastbuildtime is up to 8 hours in the future.

[johnbillion]

I'm also seeing unexpected behaviour with regards to mysql2date now respecting the site's timezone, when it previously didn't. Moving to 5.3.1 for further investigation.

[Otto42]

Quick check. Do you have any code other than WordPress core calling date_default_timezone_set. For any reason at all. All of the previous bug reports here the last few days have involved this being done.

[Rarst]

So mysql2date() is a horribly designed and implemented function, that worked primarily with local times, but treated them as UTC times and pretended that it makes sense, as long as you don't output the time zone.

Of course as soon as you output time zone, turns out that entirety of your local time handling is horribly broken.

What do you do when you do need correct time zone? Do you fix the code? No, obviously you just pass the UTC time to a function that is mostly used for local times and broken for them, but happens to work correctly for UTC because that is what it's actually doing instead of what it is used for most of the time.

So on implementation level I flipped this assumption. Now the function works correctly for all the local time inputs, but apparently not for UTC time inputs.

This was one of those places where bugfix cannot be separated from a change in behavior.

In my opinion this fixes more than it breaks?..

So the obvious strategic action is to get rid of this function entirely, and I've been eagerly cutting its use from core.

But since we still must keep it around (ugh) the question is what to do with implementation.

Choices are:

1. Keep the behavior change, keep the bug fix, document UTC input resulting in incorrect time zone.
2. Revert the behavior change, lose the bug fix, document local input resulting in incorrect time zone.

Regardless of implementation choice burn its use out of core with fire.

[Rarst]

Added patch that throws out mysql2date for the specific issue reported and adds unit test.

[SergeyBiryukov]

In 46756:

Date/Time: Remove mysql2date() usage in get_feed_build_date() to ensure the output includes correct timezone offset.

With the changes in [45908], mysql2date() works correctly for all local time inputs, but should not be used for UTC time inputs.

Add a unit test.

Props Rarst, lisota.
Fixes #48675.

[SergeyBiryukov]

Reopening for 5.3.1.

[SergeyBiryukov]

In 46757:

Date/Time: Correct the time format in get_feed_build_date() to use 24-hour format.

Follow-up to [46756].

See #48675.

[SergeyBiryukov]

In 46774:

Date/Time: Remove mysql2date() usage in get_feed_build_date() to ensure the output includes correct timezone offset.

With the changes in [45908], mysql2date() works correctly for all local time inputs, but should not be used for UTC time inputs.

Add a unit test.

Props Rarst, lisota.
Merges [46756] and [46757] to the 5.3 branch.
Fixes #48675.

[SergeyBiryukov]

In 46785:

Tests: Add feed group for get_feed_build_date() test added in [46756].

See #48675.