-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
date-fns: bump to v3.6 #60163
date-fns: bump to v3.6 #60163
Conversation
Size Change: -1.71 kB (0%) Total Size: 1.72 MB
ℹ️ View Unchanged
|
1822c8c
to
e22ab39
Compare
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you, @tyxla!
The update tests well for me ✅
Possible broken behavior on trunk
I noticed a strange behavior of the "Now" button. It resets the time to my machine's time instead of the timezone set by WP, which can lead to strange scheduling behavior.
Example:
- Open a draft post and switch the publishing date to the future.
- The save button changes the label to "Schedule."
- Switch the date back and the save button label will be restored to "Publish."
- Click on "Now" and repeat the same steps.
- Notice that the label isn't reverted to "Publish."
- Click "Now" again and the label is reverted, even though the time =< current time.
I'm not 100% sure what the intended behavior should be here, but initially, I thought it was a bug caused by the update and had to re-test it on the trunk.
Screencast
CleanShot.2024-03-28.at.12.35.54.mp4
Thanks for reporting @Mamaduka! I took a look and I'm able to reproduce on After a second look, it looks like this is intentional because of the 1-minute threshold we're adding to accommodate time differences between the server and the client, see #3036. cc @youknowriad if he has any thoughts, but I think we should leave this as-is to keep preventing the issue Riad described in the PR. |
@tyxla, even when I adjust minutes (remove 5min), I get the same result. I'll cover up my report on an issue and look into it separately. Thanks for the confirmation. |
Thanks @Mamaduka, this is definitely worth some additional attention since it might be misbehaving. Have you tried with disabling that threshold functionality manually, just to see if that resolves it for you? |
I've not, but I'll test it later. |
* bump date-fns to v3.6 * bump use-lilius to 2.0.4 * CHANGELOG * Bump use-lilius to v2.0.5 Co-authored-by: tyxla <tyxla@git.wordpress.org> Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
What?
This PR bumps
date-fns
to the latestv3.6.0
. Also bumpsuse-lilius
to the latest version (v2.0.5
) which also updateddate-fns
to v3.6.Why?
There are a bunch of fixes in it, plus some potential bundle size improvements.
How?
Just bumping some dependency versions of
date-fns
.We're suggesting a bump to the latest version at Avarios/use-lilius#499. We might need to wait until that lands and a new version is released in order to ensure we don't use multipledate-fns
versions under the hood.use-lilius@v2.0.5
was released withdate-fns@3.6.0
as a dependency yesterday, so we're using that as well to match the underlyingdate-fns
dependency version.Testing Instructions
DateTimePicker
,DatePicker
andTimePicker
components in Storybook still work well.Testing Instructions for Keyboard
None
Screenshots or screencast
None