Improve documentation for dateI18n. Standardise way to output date. Add function dateI18nAddTimezone. #26276
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
ajitbohra,
Soean and
talldan
as code owners
|
Size Change: +92 B (0%) Total Size: 1.2 MB
ℹ️ View Unchanged
|
jorgefilipecosta
added
the
[Status] In Progress
jorgefilipecosta
force-pushed
the
update/improve-documentation-for-dateI18n-function-consolidate-date-formats-to-the-format-function-instead-of-gmdateI18n-and-dateI18n
branch
from
8a1666a
to
b6fd3de
Compare
jorgefilipecosta
changed the title
jorgefilipecosta
force-pushed
the
update/improve-documentation-for-dateI18n-function-consolidate-date-formats-to-the-format-function-instead-of-gmdateI18n-and-dateI18n
branch
from
b6fd3de
to
8c8dd8a
Compare
jorgefilipecosta
removed
the
[Status] In Progress
jorgefilipecosta
force-pushed
the
update/improve-documentation-for-dateI18n-function-consolidate-date-formats-to-the-format-function-instead-of-gmdateI18n-and-dateI18n
branch
from
8c8dd8a
to
c9b26a6
Compare
|
Would it be possible to fix the issue by, instead, ensuring that date values coming from the REST API always have the appropriate timezone attached? |
Hi @mcsf, Yes having the API return the timezone, and making sure our components that produce dates, (post schedule component, post date block, etc) return dates with an attached timezone too, and making sure we always format dates with the existing dateI18n function would also be a valid fix. The question is if changing the time format returned by the WordPress API is a breaking change or not? Is it something we can do and should consider doing? cc: @TimothyBJacobs as someone very involved in rest API work in case you have some thoughts on this. |
|
Relevant core ticket: https://core.trac.wordpress.org/ticket/39855 I think it'd probably be considered a breaking change. The GMT offset is exposed in the index, so you could manually change the date fields in the client to include the timezone I suppose? |
19 tasks
…ix timezone issue on wp.date.format.
|
Does the PR fix this issue? #27251 |
jorgefilipecosta
force-pushed
the
update/improve-documentation-for-dateI18n-function-consolidate-date-formats-to-the-format-function-instead-of-gmdateI18n-and-dateI18n
branch
from
c9b26a6
to
6b09064
Compare
6 tasks
youknowriad
deleted the
update/improve-documentation-for-dateI18n-function-consolidate-date-formats-to-the-format-function-instead-of-gmdateI18n-and-dateI18n
branch
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.
This PR improves documentation for dateI18n.
Checks the codebase and standardizes the ways we output dates, mostly relying on wp.date. dateI18nAddTimezone now. This change fixes an issue that packages/block-library/src/post-date/edit.js and packages/block-library/src/post-comment-date/edit.js had similar to the one fixed in #26212.
We also fix an issue that was present in multiple blocks when outputting in a format that has a timezone representation (e.g., the 'c' format very used to output time HTML elements). The timezone used was the local one instead of the WordPress one, and the value was converted to the website timezone, making the time wrong because the date was already on the website timezone.
What we needed to output time HTML elements and to general date formats, in general, is a function that receives the time in the WordPress timezone (but whose time does not specify the timezone) adds the WordPress timezone keeping the same hours.
E.g., if we receive a string "2020-10-16T14:36:58", the website is on -4 UTC offset, and the user is on +2 UTC offset when applied the "c" format we want to output:
2020-10-16T14:36:58-04:00If we call
wp.date.format('c', '2020-10-16T14:36:58');we get `2020-10-16T14:36:58+02:00. The hours are not changed; that's why the fix in #26212 worked, but the timezone specified is not correct. It is the user timezone, and it should be the website timezone. Browsers would announce the time on the time elements incorrectly.If we call
wp.date.dateI18n('c', '2020-10-16T14:36:58');we get2020-10-16T08:36:58-04:00. The output is on the website timezone but the hours are not correct because they were converted without need.If we call
wp.date.dateI18nAddTimezone('c', '2020-10-16T14:36:58');we get the correct output2020-10-16T14:36:58-04:00.How has this been tested?
On the browser console, I made some tests to wp.date.dateI18nAddTimezone calls and verified the results were the expected ones.
I added the latest posts block, post date block, and post comment date blocks. And I verified the time element they output (using the browser inspector) is in the website timezone and matches exactly what is output on the frontend by the server. Previously the outputs between server and client did not match.