Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DatePicker: Fix day's labels for shifting by 1 in specific usr and website timezone combination #67482

Open
wants to merge 5 commits into
base: trunk
Choose a base branch
from

Conversation

MaksVeter
Copy link

@MaksVeter MaksVeter commented Dec 2, 2024

What?

Fixes the days labels become wrong after the DST time when user is in UK and Website has US Timezone.

Why?

#67480

How?

Add 15 hours to day before pathing it to Day component to avoid the DST impact described in a bug (in the similar maner as date-fns lib do)

Testing Instructions

  1. Set local UK timezone
  2. Set website US timezone (America/New_York)
  3. Go to post with Gutenberg enabled
  4. Open the post date picker
  5. find the October 2024 and November 2024
  6. Check the day's labels

Testing Instructions for Keyboard

Screenshots or screencast

Before After
image image

@MaksVeter MaksVeter requested a review from ajitbohra as a code owner December 2, 2024 15:26
Copy link

github-actions bot commented Dec 2, 2024

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

  • Type-related labels to choose from: [Type] Automated Testing, [Type] Breaking Change, [Type] Bug, [Type] Build Tooling, [Type] Code Quality, [Type] Copy, [Type] Developer Documentation, [Type] Enhancement, [Type] Experimental, [Type] Feature, [Type] New API, [Type] Task, [Type] Technical Prototype, [Type] Performance, [Type] Project Management, [Type] Regression, [Type] Security, [Type] WP Core Ticket, Backport from WordPress Core, Gutenberg Plugin.
  • Labels found: First-time Contributor.

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

Copy link

github-actions bot commented Dec 2, 2024

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: MaksVeter <maksvi@git.wordpress.org>
Co-authored-by: ntsekouras <ntsekouras@git.wordpress.org>
Co-authored-by: tyxla <tyxla@git.wordpress.org>
Co-authored-by: annezazu <annezazu@git.wordpress.org>
Co-authored-by: ciampo <mciampini@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Copy link

github-actions bot commented Dec 2, 2024

👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @MaksVeter! In case you missed it, we'd love to have you join us in our Slack community.

If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information.

@github-actions github-actions bot added the First-time Contributor Pull request opened by a first-time contributor to Gutenberg repository label Dec 2, 2024
@annezazu
Copy link
Contributor

annezazu commented Dec 6, 2024

@ntsekouras can you help resolve this here?

@annezazu
Copy link
Contributor

annezazu commented Dec 6, 2024

@tyxla can you also help review this from a components point of view?

Thanks for your first contribution @MaksVeter! Always a delight to se.

@@ -318,7 +319,7 @@ function Day( {
onClick={ onClick }
onKeyDown={ onKeyDown }
>
{ dateI18n( 'j', day, -day.getTimezoneOffset() ) }
{ dateI18n( 'j', shiftedDay, -shiftedDay.getTimezoneOffset() ) }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we go with this approach we'd need to also update the aria-label above.

@@ -303,7 +303,8 @@ function Day( {
// isFocusAllowed is not a dep as there is no point calling focus() on
// an already focused element.
}, [ isFocusable ] );

const shiftedDay = new Date( day );
shiftedDay.setHours( 15 );
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you explain a bit more about this technique? Dates have many nuances and would like to understand more about it.

Would similar changes be needed elsewhere or this could resolve this issue for the whole component?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Honestly, I'm a bit torn about doing this without any conditions. Shouldn't we be doing it only if we can verify a DST discrepancy is occurring?

@tyxla tyxla requested a review from a team December 9, 2024 14:21
@@ -303,7 +303,8 @@ function Day( {
// isFocusAllowed is not a dep as there is no point calling focus() on
// an already focused element.
}, [ isFocusable ] );

const shiftedDay = new Date( day );
shiftedDay.setHours( 15 );
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My understanding is that this sets the hours to 15:00:00, assuming that this will keep us in the same day, regardless of which timezone we are in (let me know if that's correct). However, I'm on the right track, this assumption seems flawed: it rests on the assumption that timezones won't spread more than 9 hours in the future or 15 hours in the past. However, AFAIK, timezones can range from UTC−12:00 to UTC+14:00, and that would contradict the initial assumption, and in some cases, this could still be a bug.

I'm also concerned this might create more problems, especially as we reuse time and date components and reuse them in more complex scenarios like DateRange picker (see #60971). The shifted date could then end up being used for time, which, as you can expect, would lead to unexpected results.

@ciampo
Copy link
Contributor

ciampo commented Dec 9, 2024

Maybe this is a naive question, but have we considered delegating some (most) of the logic directly to date-fns, since it's already a dependency of this project?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
First-time Contributor Pull request opened by a first-time contributor to Gutenberg repository
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants