Make WordPress Core

Opened 19 months ago

Last modified 4 months ago

#57409 new defect (bug)

Post date/time selector on a different timezone than of the server's

Reported by: rfischmann's profile rfischmann Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 6.1
Component: Date/Time Keywords:
Focuses: Cc:

Description

I've noticed this bug since updating to WordPress 6.1, but I didn't know it had anything to do with timezones until I traveled to Brazil the past couple of weeks.

My server is running on GMT-3, Brazil's timezone. While I was there, everything was ok. But here in Portugal (GMT), the post's date/time selector has a bug in which it doesn't circle the correct date on the calendar, but the previous day instead.

I'm attaching a screenshot.

Attachments (2)

Captura de Tela 2023-01-02 às 09.44.28.png (350.8 KB) - added by rfischmann 19 months ago.
CleanShot 2023-01-02 at 10.11.02.gif (2.6 MB) - added by rfischmann 19 months ago.
Bug in action

Change History (11)

#1 @Rarst
19 months ago

WordPress core is coded to ignore the server's (PHP) time zone. Though block editor is its own thing and I am not familiar with its date/time handling.

Is the output consistent with WordPress time zone, set in WordPress settings? If so then it would be "correct", even if it differs from your physical location / browser time zone.

Also note that WP isn't engineered to handle time zone changes in settings. The existing local times of posts are not changed if time zone is changed and doing that on a non-new WP site can lead to unexpected and unwanted results.

#2 @rfischmann
19 months ago

It's not consistent, @Rarst. Even if I try to schedule the post for a future date, the calendar always circles the previous day. I'm not basing it on my timezone, but the server's.

It also has nothing to do with changes in the settings. It's just how the editor behaves when the user is on a different timezone than of the server's.

#3 @Rarst
19 months ago

if I try to schedule the post for a future date, the calendar always circles the previous day

Gotcha, that does sound like a wrong behavior.

It's just how the editor behaves when the user is on a different timezone than of the server's.

This is the part that I am trying to clarify here. To enumerate there are following time zones typically involved:

  1. Time zone as set in server's PHP settings (WP core should ignore it under normal operation).
  2. Time zone as set in WordPress settings (this should be used by WP in all cases).
  3. Time zone as set in user's browser (this should be ignore by WP core, but I think sometimes leaks into block editor part, it being front-end JS application rather than part of WP's historical PHP core).

So when you say "user" and "server", which settings _exactly_ do you mean, where difference causes the observed error? Could you please provide exact example to reproduce? Like "my WordPress is set to time zone [value], my browser is set to time zone [value]".

#4 @rfischmann
19 months ago

Understood.

Both my server and WordPress are set to Brazil's timezone (GMT-3). My computer (macOS/Firefox) is currently running on Portugal's timezone (GMT), which then breaks the date/time selector in the post.

The conflict only occurs when my local timezone is different than my site's.

#5 @Rarst
19 months ago

Can't reproduce this so far... I've noticed your date picker has DATA section in different order from what I get on clean WP install.

What is your exact WP version?
Do you use just block editor as it or have Gutenberg plugin installed?

#6 @rfischmann
19 months ago

Isn't that because the U.S. uses MM-DD-YYYY, while the rest of the world uses DD-MM-YYYY?

I'm running WP 6.1.1, native block editor (not the Gutenberg plugin).

#7 @Rarst
19 months ago

I thought it was tied to locale at first, but it doesn't seem to be affected if I set WP to Portuguese (I am guessing, given Brazil?), so I am not sure what controls the order there and if it's relevant (again, block editor not my part of this :).

#8 @rfischmann
9 months ago

This bug was fixed back in WordPress 6.2, I reckon, but it's now back as Europe's daylight saving time ended yesterday.

Or maybe it wasn't fixed at all, and it was working fine while DST was on? I don't know for sure.

#9 @rfischmann
4 months ago

This seems to have been fixed in WordPress 6.5, or either once again it's because we've entered DST last Sunday. 🤷🏼‍♂️

Last edited 4 months ago by rfischmann (previous) (diff)
Note: See TracTickets for help on using tickets.