Fix: Post schedule label showing wrong time if site and user timezones did not match #26212
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jorgefilipecosta
added
[Type] Bug
jorgefilipecosta
requested review from
youknowriad,
ryelle,
gziolo and
whyisjake
|
Size Change: -4 B (0%) Total Size: 1.19 MB
ℹ️ View Unchanged
|
youknowriad
reviewed
Oct 19, 2020
| import { withSelect } from '@wordpress/data'; | ||
|
|
||
| export function PostScheduleLabel( { date, isFloating } ) { | ||
| const settings = __experimentalGetSettings(); | ||
|
|
||
| return date && ! isFloating | ||
| ? dateI18n( |
There was a problem hiding this comment.
It seems the intent of that function is not clear. Does it assume that the passed date is a given timezone? Should we remove that assumption? Should we clarify it in the description of the function.
Anyway, it seems like the current fix is good anyway but there might be something wrong with dateI18n
There was a problem hiding this comment.
I think by default the dateI18n assumes the time is in the user's timezone and formats it in the website time zone.
I think we may have other cases where we are using dateI18n for dates that are already on the website timezone. I will try to propose a follow-up PR that improves documentation for this function and maybe fixes additional issues.
|
To confirm, this backport is aimed at 5.5.2, right? |
|
Correct @tellthemachines. |
|
I didn't realize that we might have a minor backport too during the "beta" phase of a major. We might want to have two separate labels for these? |
|
We could try that! Are you thinking something like "Backport to WP Core - Minor" and "- Major", or labelling by target version? |
|
@tellthemachines Yes, this works for me to avoid ambiguity |
|
@youknowriad which of them works? Differentiating by minor/major, or having a different label for each target version? |
|
I prefer just two labels personally because we explicitly remove the label once the backport is made but both work tbh. |
noisysocks
added
Backport to WP Minor Release
noisysocks
added a commit
that referenced
this pull request
Oct 29, 2020
* Refactor BlockMover to use React hooks (#24774) * Add drag handle to block toolbar (#24852) * Add drag handle to block mover component * Switch draggable chip to reflect toolbar layout * Use drag cursor * Hide drag handle on mobile or in top toolbar mode * Adjust handle and structure. * Size the switcher. * Adjust mover. * Update icon for handle. * Update movers buttons. * Fix groups. * Focus for switcher. * Handle focus. * Fix top toolbar. * Popover fix. * Fix spacing issue. * Harmonize spacing. * Try small independen transition for up / down. * Reduce motion. * use dragHandle icon in draggable chip * Make draggable chip use same icon as toolbar * Revert "Make draggable chip use same icon as toolbar" This reverts commit d031006. * Revert offset change and ensure cursor does not overlap chip block info * Update snapshots to reflect chevron icon change Co-authored-by: jasmussen <joen@automattic.com> Co-authored-by: Matías Ventura <mv@matiasventura.com> * Fix issue with single block. (#25107) * Remove animation from mover buttons. (#25728) The animation was intended to better convey direction, and were added as an experiment. It doesn't seem successful, so let's remove it again. * add label in drag and drop button (#25606) * Change toolbar drag remove labels (#25614) * Refactor toolabar drag+remove labels * fix tests * fixes #24845 (#24847) * Fix: Post schedule label showing wrong time if site and user timezones did not match (#26212) * URLInput: Use debounce() instead of throttle() (#26529) Wait until the user finishes typing before sending an AJAX request. This ensures that there isn't an AJAX request sent every 200 ms while the user is typing. * Update browserlist dependency (#24756) * Fix composer test failures due to invalid lock (#26472) * Update package-lock.json * Set dev environment to use WordPress 5.5 Co-authored-by: Chris Alexander <cmalex@gmail.com> Co-authored-by: Daniel Richards <daniel.richards@automattic.com> Co-authored-by: jasmussen <joen@automattic.com> Co-authored-by: Matías Ventura <mv@matiasventura.com> Co-authored-by: Joen A <1204802+jasmussen@users.noreply.github.com> Co-authored-by: Nik Tsekouras <ntsekouras@outlook.com> Co-authored-by: Ari Stathopoulos <aristath@gmail.com> Co-authored-by: Jorge Costa <jorge.costa@automattic.com> Co-authored-by: Riad Benguella <benguella@gmail.com> Co-authored-by: Marcus Kazmierczak <marcus@mkaz.com>
noisysocks
removed
the
Backport to WP Minor Release
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes: https://core.trac.wordpress.org/ticket/50949#comment:29
Previously the issue happened just on the core but if the Gutenberg plugin was installed the issue did not happen.
Recently the issue started appearing also with Gutenberg installed. That happened after PR #22866 was merged.
On PR #22866 it is referred that core already used a higher version of moment-timezone than the one previously used on Gutenberg. That explains why previously the issue happened on the core but not on Gutenberg.
It seems the update is not the issue in fact it seems before the update there was a bug in the library that made our code work well.
The date we have in select( 'core/editor' ).getEditedPostAttribute( 'date' ) is on the timezone of the website and does not needs any conversion. We just want to format it in a pretty way to show it to the user. The function dateI18n that was previously being used assumes the date is in a different timezone and then changes the time to the site time zone making the time appear wrong because the time was already in that timezone.
What I did was instead of calling dateI18n just use format because we just want to format the date given that it is already on the site timezone.
The component DateTime was showing the correct date and that component was just doing format calls packages/components/src/date-time/time.js, so this change makes PostScheduleLabel consistent with that.
How has this been tested?
Se your test website to a timezone that is different from the one on your computer.
On master Create a post and publish it verify the date shown as publishing date on the document sidebar is not correct (according to the website timezone). Click the date and open the post scheduler to verify the date there is correct according to the site time zone.
On this branch repeat the previous step and verify the post publish date now shows the correct date.