WordPress.org

Make WordPress Core

Opened 11 months ago

Closed 9 months ago

#51761 closed enhancement (invalid)

Inconsistent displayed date in get_calendar()

Reported by: labbit Owned by:
Milestone: Priority: normal
Severity: minor Version:
Component: Date/Time Keywords: has-screenshots reporter-feedback
Focuses: Cc:

Description

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

Attachments (5)

2020-11-12_11-47-43.png (8.2 KB) - added by labbit 11 months ago.
Wrong calendar for Novembre, displayed days are +1
2020-11-12_11-48-21.png (30.3 KB) - added by labbit 11 months ago.
Inconsistent HTML: aria label is different from printed day
site-health.png (54.2 KB) - added by labbit 11 months ago.
Site Health scan
grep-plugins.png (518.3 KB) - added by labbit 11 months ago.
Grep wp-content/plugins
utc-settings.png (18.8 KB) - added by labbit 11 months ago.
UTC settings in wordpress

Download all attachments as: .zip

Change History (17)

@labbit
11 months ago

Wrong calendar for Novembre, displayed days are +1

@labbit
11 months ago

Inconsistent HTML: aria label is different from printed day

#1 @SergeyBiryukov
11 months ago

  • Summary changed from Bug in get_calendar() to Inconsistent displayed date in get_calendar()

#2 @Rarst
11 months ago

  • Summary changed from Inconsistent displayed date in get_calendar() to Bug in get_calendar()

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.

#3 @Rarst
11 months ago

  • Summary changed from Bug in get_calendar() to Inconsistent displayed date in get_calendar()

Title revert was unintended. :)

#4 @desrosj
11 months ago

  • Keywords reporter-feedback added
  • Version trunk deleted

#5 follow-up: @labbit
11 months ago

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?

#6 in reply to: ↑ 5 @SergeyBiryukov
11 months ago

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

#7 @Rarst
11 months ago

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?

#8 @labbit
11 months ago

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
11 months ago

Site Health scan

@labbit
11 months ago

Grep wp-content/plugins

@labbit
11 months ago

UTC settings in wordpress

#9 follow-up: @Rarst
11 months ago

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.

#10 in reply to: ↑ 9 @labbit
11 months ago

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.

#11 @labbit
9 months ago

  • Severity changed from normal to minor
  • Type changed from defect (bug) to enhancement

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.

#12 @Rarst
9 months ago

  • Keywords needs-patch removed
  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

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.

Note: See TracTickets for help on using tickets.