WordPress.org

Make WordPress Core

Opened 4 months ago

Closed 5 weeks ago

#50949 closed defect (bug) (fixed)

Posts show wrong time when user is in a different time zone than the site's

Reported by: rfischmann Owned by:
Milestone: 5.5.2 Priority: normal
Severity: major Version: 5.5
Component: Date/Time Keywords: needs-patch
Focuses: Cc:

Description

I'm in GMT+1, my site is configured in GMT-3 time zone — so I'm 4 hours ahead.

WordPress' editor in version 5.5 is showing the post's time as if it was published 4 hours before, example: https://d.pr/i/wAw9iV

If I click the post's date/time, it shows the correct time: https://d.pr/i/L4TlQd

Just so it's completely clear: that post was published at 11:41AM GMT-3, and that was 3:41PM GMT+1 for me.

So the editor is considering that my time zone should be the post's, and it's then subtracting 4 hours because of the time zone difference. Very weird behavior.

Change History (32)

#1 @rfischmann
4 months ago

#50950 was marked as a duplicate.

#2 @johnbillion
4 months ago

  • Component changed from General to Date/Time
  • Keywords needs-testing added
  • Milestone changed from Awaiting Review to 5.5.1

Thanks for the report @rfischmann and welcome to WordPress Trac. Can you confirm this issue exists with all your plugins deactivated?

Moving to 5.5.1 for visibility regardless.

#3 @johnbillion
4 months ago

  • Keywords reporter-feedback added; needs-testing removed

Also, can you please check your Tools -> Site Health screen and see if there's a warning about your time zone setting? I suspect this is the cause if so.

More info here: https://github.com/johnbillion/wp-crontrol/wiki/PHP-default-timezone-is-not-set-to-UTC

#4 @rfischmann
4 months ago

Hey @johnbillion,

I can confirm the issue exists with all plugins deactivated.

No warnings about time zone there, either.

#5 @Rarst
4 months ago

Can reproduce in my local install, the displayed time in sidebar switches if time zone is switched. Only seems to happen with named time zones, doesn't happen if UTC offset time zone is selected.

Time is correct elsewhere in admin, as well as returned correctly from API calls in PHP.

Borked somewhere in Gutenberg? I have no idea how is this implemented in new editor.

This ticket was mentioned in Slack in #core-datetime by rarst. View the logs.


4 months ago

This ticket was mentioned in Slack in #core-editor by rarst. View the logs.


4 months ago

#8 @johnbillion
4 months ago

  • Keywords needs-patch added; reporter-feedback removed

This ticket was mentioned in Slack in #forums by joyously. View the logs.


4 months ago

#10 @Otto42
4 months ago

I can't seem to reproduce on a trunk install.

Possibly something with the language settings? Check the site language and see if it happens in some but not others.

Also check to see if the values for the post in post_date and post_date_gmt are set correctly in the database.

#11 @rfischmann
4 months ago

Hi @Otto42,

I've just temporarily switched my installation from Portuguese (Brazil) to English and the issue remained.

Also checked a post that was published today at 9:57AM GMT-3 (which was 1:57PM GMT+1 for me, but I'm seeing as 5:57AM in WordPress), post_date is set as "2020-08-13 09:57:03" and post_date_gmt is set as "2020-08-13 12:57:03". It seems perfect to me.

Last edited 4 months ago by rfischmann (previous) (diff)

#12 @Otto42
4 months ago

@rfischmann If I switch my test site to Portuguese (Brazil), then I see this in the sidebar for a test post:

Publicar agosto 13, 2020 12:04 pm

As you seem to have a different format for the time being displayed in your screenshot, including having the time shown twice, then I have to ask what settings you have for the Date and Time Formats on the Settings->General page?

#13 @rfischmann
4 months ago

@Otto42 Wow, I hadn't even noticed the time was shown twice there. Haha.

Here you go: https://d.pr/i/z3nubw

#14 @Rarst
4 months ago

For the record I was able to reproduce in vanilla English install, site language is not a factor.

#15 @Otto42
4 months ago

@Rarst How can I reproduce this? I set my timezone to America/Chicago, as I always do, and it works fine.

What settings do I need to set to reproduce the problem?

#16 @Rarst
4 months ago

  1. Publish a post
  2. Change site settings to a different named (this seems to matter) time zone
  3. Observe admin post list displaying same local time for the post
  4. Observe editor sidebar display different local time for the post

Specific example:

  1. My timezone is Europe/Kiev
  2. I dated a post 8:00am today
  3. Posts list shows 8:00am, editor shows 8:00am
  4. I changed time zone to Europe/Amsterdam
  5. Posts list shows 8:00am (correct), editor shows 7:00am (incorrect)
Last edited 4 months ago by Rarst (previous) (diff)

#17 @rfischmann
4 months ago

Sorry, the date format isn't fully visible on the screenshot I've sent before.

It's set to "d/m/Y • H:i", that's why it's shown twice there.

But that has no relation to the time zone bug, I reckon.

#18 @Otto42
4 months ago

Okay, thanks, I can see the problem now. The offset is incorrectly being applied to the post date by the editor.

Notably, the latest Gutenberg plugin, version 8.7.1, does not exhibit this problem. So as a temporary fix, you can likely just install and activate the Gutenberg plugin to eliminate the problem.

Last edited 4 months ago by Otto42 (previous) (diff)

#19 @brettshumaker
4 months ago

Also noting that version 8.5.1 of the Gutenberg plugin does not have this issue either.

This ticket was mentioned in Slack in #core by david.baumwald. View the logs.


4 months ago

#21 @papayoulele
3 months ago

#51150 was marked as a duplicate.

#22 follow-up: @Rarst
3 months ago

What's exactly the plan relative to core if this is something Gutenberg plugin has fixed?

Will 5.5.1 receive a Gutenberg version bump? Does someone need to port this specifically over from plugin to core?

#23 in reply to: ↑ 22 @SergeyBiryukov
3 months ago

Replying to Rarst:

What's exactly the plan relative to core if this is something Gutenberg plugin has fixed?

Some packages will be updated in #51151.

I guess we need to see if this fix is included in the backports: https://github.com/WordPress/gutenberg/pull/24828

This ticket was mentioned in Slack in #core by desrosj. View the logs.


3 months ago

#25 @jorgefilipecosta
3 months ago

  • Milestone changed from 5.5.1 to 5.5.2

Hi, I did some tests to the issue, and the issue in fact does not happen with Gutenberg plugin. But there was no PR since 5.5 that fixed the issue in the plugin that we can backport. If we install the same Gutenberg plugin version that was included in 5.5 the issue also does not happen.
So when the plugin is installed just by having the plugin, there is no issue. I guess there is a difference between how core and the plugin pass data and we need a fix the issue in core. Unfortunately, I guess we are not on time to include this fix in 5.5.1 so I will change the milestone to 5.5.2.

#26 @rfischmann
3 months ago

I've just installed Gutenberg 9.0.0 and the issue is still there.

#27 @parkcityj
2 months ago

Installing Gutenberg 8.9.3 also solves the issue, so it seems like the regression happened between 8.9.3 and 9.0.0

This ticket was mentioned in Slack in #core by audrasjb. View the logs.


7 weeks ago

#29 @audrasjb
7 weeks ago

Hey hey @jorgefilipecosta do you think this issue can be backported in 5.5.2, like in the next dozen of days? It would be wonderful :)

Thanks, Jb

#30 @jorgefilipecosta
7 weeks ago

So the issue happened on the core but not on Gutenberg because Gutenberg used an older version of a library that had some issue that by luck made the things work.
Meanwhile, that library was also updated on Gutenberg and things also stopped working with Gutenberg.
I'm proposing a fix on Gutenberg in PR https://github.com/WordPress/gutenberg/pull/26212.

#31 @noisysocks
5 weeks ago

In 49372:

Editor: Update packages

@wordpress/block-directory: 1.13.7 -> 1.13.8
@wordpress/block-editor: 4.3.7 -> 4.3.8
@wordpress/block-library: 2.22.7 -> 2.22.8
@wordpress/blocks: 6.20.3 -> 6.20.4
@wordpress/components: 10.0.6 -> 10.0.7
@wordpress/core-data: 2.20.3 -> 2.20.4
@wordpress/edit-post: 3.21.7 -> 3.21.8
@wordpress/editor: 9.20.7 -> 9.20.8
@wordpress/format-library: 1.22.7 -> 1.22.8
@wordpress/icons: 2.4.0 -> 2.4.1
@wordpress/list-reusable-blocks: 1.21.6 -> 1.21.7
@wordpress/nux: 3.20.6 -> 3.20.7
@wordpress/plugins: 2.20.3 -> 2.20.4
@wordpress/server-side-render: 1.16.6 -> 1.16.7

Props talldanwp.
See #51659, #51053, #50949.

#32 @noisysocks
5 weeks ago

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.