Repository navigation
DataViews: Store the clicked calendar day in the datetime control across timezones - #81637
jorgefilipecosta wants to merge 2 commits into
Conversation
|
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.
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. |
|
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 If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Size Change: +23 B (0%) Total Size: 7.74 MB 📦 View Changed
|
ca84176 to
6cee1c2
Compare
|
Flaky tests detected in 6cee1c2. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/32280805629 Should save the changes in
|
|
Closing as superseded by #81498 (which should cover the same fix + additional improvements). @jorgefilipecosta please check #81498 and feel free to re-open this PR in case I misinterpreted |
When the site timezone is behind the timezone the calendar is rendered in, clicking a day in the Datetime DataForm control's calendar stores the previous day. The calendar hands back the clicked day as a
Datebuilt from its displayed day, and converting that instant withdateI18n( 'Y-m-d', … )re-expresses it in the site timezone, shifting it across midnight. For example, with the site timezone at UTC and a browser at UTC+1, clicking "October 14" stores October 13.The fix reads the selected day through the date's own fields with
format( newDate, 'yyyy-MM-dd' ), the same way the plain date control already reads its selections, and uses the start of the selected day as the fallback when there is no time to preserve. The time of an existing value is still preserved in the site timezone.Discovered while preparing #81635. A broader follow-up worth considering separately: for sites configured with a manual offset (no named timezone), the calendar's
timeZoneprop falls back to the browser timezone, so day highlighting and the "today" marker also render in the wrong frame across the date controls; rendering the calendar in the site timezone would need an offset-basedtimeZonevalue and has browser-compatibility implications, so it is intentionally out of scope here.Testing Instructions
The unit test can be run with:
Before (video): clicking October 14 stores October 13.
After (video): clicking October 14 stores October 14.
Note: this branch and #81635 both touch
datetime.tsxand add to the same test file, so whichever lands second needs a trivial rebase.AI tools were used to assist in the preparation of this PR.