Inconsistent displayed date in get_calendar()

[labbit]

This bug was introduced with this commit:
​https://github.com/WordPress/wordpress-develop/commit/10855438eaca4da1aa24616fdc5f90f5745a45e4#diff-1c6b59f268c3016f96c2f2ac62c15a4990045a68fd56aa2c36ef8e1853362bcb

By using gmdate with strtime or mktime you are mixing local times with gm times. get_calendar() has a bug now, because displayed day is different from the day used in queries. For example you display November 1, but using gmtime it becomes Oct 31 for all countries after Greenwich line

[labbit]

Wrong calendar for Novembre, displayed days are +1

[labbit]

Inconsistent HTML: aria label is different from printed day

[Rarst]

Please check that your environment isn't using date_default_timezone_set(). WordPress core is historically hardcoded to operate in UTC on PHP level so there is no discrepancy with "local" time.

[Rarst]

Title revert was unintended. :)

[labbit]

Checked this morning:

• php.ini reports timezone to UTC, the same in phpinfo()
• WordPress settings has "Rome" as timezone. When I set to "UTC" the calendar is fixed and layout is correct.

Does it mean we cannot set Local Timezone in wordpress settings?

[SergeyBiryukov]

Replying to labbit:

Does it mean we cannot set Local Timezone in wordpress settings?

No, it's more likely that a plugin or theme changes PHP time zone with date_default_timezone_set(), which is not recommended. See [46797] / #48692 and ​Date/Time component improvements in WordPress 5.3 for more details.

• Does the issue still happen with all plugins disabled and a default theme (Twenty Twenty) activated?
• Do you have a warning like this in Site Health? "PHP default timezone was changed after WordPress loading by a date_default_timezone_set() function call. This interferes with correct calculations of dates and times."

[Rarst]

php.ini is irrelevant to WordPress, it explicitly overrides PHP time zone to UTC during core boot.

No, the WordPress time zone setting is completely fine to use. The point is if something overrides PHP time zone setting from UTC then things break in WP.

There is a check for this in Tools > Site Health, try running that, please?

[labbit]

Please check the new attachments.
Running Site Health shows correct timezone, also I did the following greps:

grep -ir "date_default_timezone_set" wp-content/themes

which returned nothing.
And then

grep -ir "date_default_timezone_set" wp-content/plugins

which returned the screenshot I attached.
There are no relevant overrides of timezone.

The calendar is working only if I set Local time to UTC in WordPress general settings.

[labbit]

Site Health scan

[labbit]

Grep wp-content/plugins

[labbit]

UTC settings in wordpress

[Rarst]

I do see overrides in ajax-event-calendar there, though it seems like it might be trying to set it back and forth.

Have you tried to reproduce with a core theme and plugins disabled, if possible?

Also to be clear, which calendar we are talking about? I assumed that's from post publish interface initially, but it doesn't look like that one.

[labbit]

I do see overrides in ajax-event-calendar there, though it seems like it might be trying to set it back and forth.

Have you tried to reproduce with a core theme and plugins disabled, if possible?

I will try to test with all plugins disabled

Also to be clear, which calendar we are talking about? I assumed that's from post publish interface initially, but it doesn't look like that one.

All the widgets based on get_calendar() are affacted by this behavior.

[labbit]

Hello,
the plugin that caused the issue was ajax-event-calendar, doing this:

function localize_plugin($page) {
        load_plugin_textdomain(AEC_NAME, false, AEC_NAME . '/locale/');
        $timezone = get_option('timezone_string');
        if ($timezone) {
                        date_default_timezone_set($timezone);
        } else {
                        // TODO: look into converting gmt_offset into timezone_string
                        date_default_timezone_set('UTC');
        }
        
        ...
}

Anyway, if you substituted date with gmdate in that commit, I still believe you should subst mktime with gmmktime, too.

Thanks for you support.

[Rarst]

Yep, that breaks things.

The plan is indeed to proof core against PHP time zone being messed with, but it's not an easy transition. There are open issues on replacing the next round of functions I think.