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

Date: Add timezone hint #23400

Merged
merged 10 commits into from
Jul 9, 2020
Merged

Date: Add timezone hint #23400

merged 10 commits into from
Jul 9, 2020

Conversation

obenland
Copy link
Member

@obenland obenland commented Jun 23, 2020

Description

This will add timezone information to the schedule post UI for users whose local timezone differs from the timezone set for the site. It shows the timezone abbreviation and a tooltip on hover with the full timezone name and UTC offset.

Fixes #15673.

How has this been tested?

Tested locally with various timezones set in wp-admin.

To test:

  • Got to Settings > General and select a timezone for your site.
  • In the "Document" sidebar panel, click on the publish date to bring up the publish calender.
  • Make sure the timezone information at the end of time component only gets displayed when your local timezone is different from the site's timezone.

Screenshots

82586619-b386d800-9b4c-11ea-8770-55bec0448124

Types of changes

New feature (non-breaking change which adds functionality)

Checklist:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.
  • My code has proper inline documentation.
  • I've included developer documentation if appropriate.
  • I've updated all React Native files affected by any refactorings/renamings in this PR.

@obenland obenland added [Type] Enhancement A suggestion for improvement. [Feature] Document Settings Document settings experience [Package] Components /packages/components labels Jun 23, 2020
@obenland obenland self-assigned this Jun 23, 2020
@github-actions
Copy link

github-actions bot commented Jun 23, 2020

Size Change: +362 B (0%)

Total Size: 1.14 MB

Filename Size Change
build/block-editor/index.js 115 kB +8 B (0%)
build/block-editor/style-rtl.css 10.8 kB +1 B
build/block-editor/style.css 10.8 kB +1 B
build/block-library/index.js 130 kB +2 B (0%)
build/blocks/index.js 48.2 kB +1 B
build/components/index.js 199 kB +258 B (0%)
build/components/style-rtl.css 15.9 kB +28 B (0%)
build/components/style.css 15.8 kB +24 B (0%)
build/date/index.js 5.38 kB +3 B (0%)
build/edit-post/index.js 304 kB +4 B (0%)
build/edit-post/style-rtl.css 5.59 kB +17 B (0%)
build/edit-post/style.css 5.58 kB +17 B (0%)
build/editor/index.js 45 kB -1 B
build/format-library/index.js 7.71 kB -1 B
ℹ️ View Unchanged
Filename Size Change
build/a11y/index.js 1.14 kB 0 B
build/annotations/index.js 3.67 kB 0 B
build/api-fetch/index.js 3.39 kB 0 B
build/autop/index.js 2.82 kB 0 B
build/blob/index.js 620 B 0 B
build/block-directory/index.js 7.67 kB 0 B
build/block-directory/style-rtl.css 944 B 0 B
build/block-directory/style.css 945 B 0 B
build/block-library/editor-rtl.css 7.54 kB 0 B
build/block-library/editor.css 7.54 kB 0 B
build/block-library/style-rtl.css 7.75 kB 0 B
build/block-library/style.css 7.76 kB 0 B
build/block-library/theme-rtl.css 728 B 0 B
build/block-library/theme.css 729 B 0 B
build/block-serialization-default-parser/index.js 1.88 kB 0 B
build/block-serialization-spec-parser/index.js 3.1 kB 0 B
build/compose/index.js 9.56 kB 0 B
build/core-data/index.js 11.4 kB 0 B
build/data-controls/index.js 1.29 kB 0 B
build/data/index.js 8.46 kB 0 B
build/deprecated/index.js 772 B 0 B
build/dom-ready/index.js 569 B 0 B
build/dom/index.js 3.23 kB 0 B
build/edit-navigation/index.js 10.8 kB 0 B
build/edit-navigation/style-rtl.css 1.08 kB 0 B
build/edit-navigation/style.css 1.08 kB 0 B
build/edit-site/index.js 16.6 kB 0 B
build/edit-site/style-rtl.css 3.03 kB 0 B
build/edit-site/style.css 3.03 kB 0 B
build/edit-widgets/index.js 9.35 kB 0 B
build/edit-widgets/style-rtl.css 2.45 kB 0 B
build/edit-widgets/style.css 2.45 kB 0 B
build/editor/editor-styles-rtl.css 537 B 0 B
build/editor/editor-styles.css 539 B 0 B
build/editor/style-rtl.css 3.78 kB 0 B
build/editor/style.css 3.78 kB 0 B
build/element/index.js 4.65 kB 0 B
build/escape-html/index.js 733 B 0 B
build/format-library/style-rtl.css 547 B 0 B
build/format-library/style.css 548 B 0 B
build/hooks/index.js 2.13 kB 0 B
build/html-entities/index.js 622 B 0 B
build/i18n/index.js 3.56 kB 0 B
build/is-shallow-equal/index.js 709 B 0 B
build/keyboard-shortcuts/index.js 2.52 kB 0 B
build/keycodes/index.js 1.94 kB 0 B
build/list-reusable-blocks/index.js 3.12 kB 0 B
build/list-reusable-blocks/style-rtl.css 476 B 0 B
build/list-reusable-blocks/style.css 476 B 0 B
build/media-utils/index.js 5.32 kB 0 B
build/notices/index.js 1.79 kB 0 B
build/nux/index.js 3.4 kB 0 B
build/nux/style-rtl.css 671 B 0 B
build/nux/style.css 668 B 0 B
build/plugins/index.js 2.56 kB 0 B
build/primitives/index.js 1.4 kB 0 B
build/priority-queue/index.js 789 B 0 B
build/redux-routine/index.js 2.85 kB 0 B
build/rich-text/index.js 13.9 kB 0 B
build/server-side-render/index.js 2.71 kB 0 B
build/shortcode/index.js 1.7 kB 0 B
build/token-list/index.js 1.28 kB 0 B
build/url/index.js 4.06 kB 0 B
build/viewport/index.js 1.85 kB 0 B
build/warning/index.js 1.13 kB 0 B
build/wordcount/index.js 1.17 kB 0 B

compressed-size-action

@retrofox
Copy link
Contributor

Getting some issues when testing with some timezones:

react_devtools_backend.js:6 Moment Timezone has no data for America/Argentina/Buenos_Aires. See http://momentjs.com/timezone/docs/#/data-loading/. 

image

I think it produces the UTC that doesn't render properly?

Screen Shot 2020-06-23 at 4 08 06 PM

I'd expect to see UTC-3 below, in the red square.

@obenland
Copy link
Member Author

Yes, this PR relies pretty heavily on the data that is bundled with Moment. For your timezone it doesn't seem to contain proper timezone abbreviations.

I've not come across the "Moment Timezone has no data" error before. Does that happen for all timezones you tested with?

@retrofox
Copy link
Contributor

I've not come across the "Moment Timezone has no data" error before. Does that happen for all timezones you tested with?

It happens for all timezones. Maybe because I'm testing with WP 5.3?

image

@jasmussen
Copy link
Contributor

Thanks for the PR!

Before:

Screenshot 2020-06-24 at 08 15 12

After:

Screenshot 2020-06-24 at 08 15 51

Don't mind the visual changes, a good rebase should take care of that.

Nice, this does seem to show the correct UTC for me.

I noticed that the entire window closes as soon as you click AM/PM or a date. That's not a regression of this PR and exists in the master branch, but seems like a regression nonetheless, right?

close

Functionality wise, and UI wise, this looks fine enough. Though we probably need a way for a keyboard user to learn this information. It looks like it's enough to simply add tabindex="0" to the div holding the UTC information, but we might need a role too. CC: @enriquesanchez in case you have anything to add here.

@enriquesanchez
Copy link
Contributor

I'm not sure what role would be appropriate for this piece of information. I'm also not sure if tabbing to it is the right approach, given that the user can't really interact with this content, it's purely informational.

Let me do some research and ask around and I will get back to you ASAP.

@enriquesanchez enriquesanchez added the Needs Accessibility Feedback Need input from accessibility label Jun 24, 2020
@enriquesanchez
Copy link
Contributor

I'm also not sure if tabbing to it is the right approach, given that the user can't really interact with this content, it's purely informational.

Looks like I was wrong here. I asked for some feedback from the Accessibility team, and looks like this element can be focusable, as Joen suggested, because the tooltip is the interaction.

Note that when I hear "tooltip on hover" I immediately red flag that. That would actually mean that it should be focusable, and the focus should give access to the tooltip. In that case, it should not be tied via aria-describedby, it should just be a tabstop where the timezone is disclosed.

It is interactive if there's a keyboard-accessible tooltip associated with it. The interaction is that on focus, further information is disclosed.

Thanks to @joedolson for the feedback and help.

@enriquesanchez enriquesanchez removed the Needs Accessibility Feedback Need input from accessibility label Jun 24, 2020
@afercia
Copy link
Contributor

afercia commented Jun 25, 2020

After some conversation on Slack and after reading the related issue, I'm not fully sure this feature should be in core.

Quoting form the issue:

For multi users blog (in multiple time zones) it is not clear what time zone a scheduled post is being set to.

This doesn't appear to be a need for the vast majority of wp.org users. It is a need for a very specific group of users. This fact alone sounds like it should be plugin territory.

One of the points on the related issue #15673 mentions this as well:

(5) Don't change in core or Editor and leave for a plugin to change ...

Given the above, and given the accessibility concerns discussed on Slack, I'd highly recommend to ship this feature in a plugin so that it can be used where it's really relevant: multi users blogs.

@obenland
Copy link
Member Author

Thank you for that feedback—I agree, it's not super useful for users that are in the same timezone as the site they're working on.

I updated the PR to only display timezone information when the user timezone differs from the site timezone. That way it only gets displayed for users where that information is relevant.

@jeffpaul
Copy link
Member

As someone who regularly schedules posts on both multi-user and single-user sites and who gets frustrated not knowing when the post is really scheduled for, seeing this PR land would make my life much easier when it comes to scheduling content. I have single-user sites that I've set up over time and I've moved across multiple timezones, so I always forget what timezone I may have set a site up on. And contrary to the latest commit on this PR, even if my local timezone matches that of the site I'd still want to see what timezone is being used as a comforting reminder that the time I'm scheduling in fact does match my local timezone.

IOU a round of tacos and preferred paired drink for getting this into core.

@obenland
Copy link
Member Author

@ajitbohra @chrisvanpatten @youknowriad Do you have any advice on next steps for this PR? is there anyone I should ping for review?

@jasmussen jasmussen requested a review from a team July 1, 2020 07:39
@obenland
Copy link
Member Author

obenland commented Jul 6, 2020

Is there anything I can do to encourage a review of this PR?

@draganescu
Copy link
Contributor

I rebased this PR and tried to test it locally but for some reason the TZ indicator doesn't show up:

Screenshot 2020-07-07 at 19 29 08

I did set WP timezone to be different from system. What am I doing wrong?

@obenland
Copy link
Member Author

obenland commented Jul 7, 2020

@draganescu When you select one of the UTC+/-X options in the timezone dropdown it currently doesn't display the timezone info since there is no additional info to populate the popup.

@obenland
Copy link
Member Author

obenland commented Jul 7, 2020

I'm now running into the same error as @retrofox earlier. Is there anything I can do to make sure the timezone information is bundled and available? @mkaz Do you know by chance?

@jeffpaul
Copy link
Member

jeffpaul commented Jul 7, 2020

@obenland any chance that's affected by core bumping moment.js? https://core.trac.wordpress.org/ticket/50408

@mkaz
Copy link
Member

mkaz commented Jul 7, 2020

I'm looking now. There is a second npm package called moment-timezone that I believe is also required, I'm not sure how it all gets bundles and included.

@mkaz
Copy link
Member

mkaz commented Jul 7, 2020

ok, I can commit this to the branch, but don't want to step on any toes,
I think this patch will do what we want and remove the dependency on Moment.

One thing lost is the zoneAbbr that is nice, mapping UTC-7 to PDT, but I think we can get that a different way without requiring moment. I think we could add that zone abbreviation to getDateSettings() in date package, the string and offset are already there.

-- redacted --

@mkaz
Copy link
Member

mkaz commented Jul 8, 2020

Ok, after taking a deeper look and going to the source of the system timezone, it is easier to export the timezone abbreviation from PHP, than trying to recreate using Moment.

I committed this change 9ed1320 that updates the date settings ouput via inline-script to include a new abbr property. The abbreviated timezone is calculated using PHP date/time functions.

This removes the need to include moment for this component.

It works if the string is set to a city/locale, for example America/New_York, or America/Los_Angeles showing the appropriate abbreviated timezone (EDT or PDT). If a UTC time is set, for example UTC-7, it will show that as the abbreviated value, because the timezone set to UTC-7 is not enough info to know the short timezone, for example: is it because it is pacific daylight time, or mountain regular time.

I believe this does what we want. Please test it out by changing your WordPress timezone setting, if it differs from your user timezone (as defined by your browser) than it will show the tool tip.

Thanks @obenland for continuing the effort here and the ping, this has been a long-standing issue I've wanted to resolve. A bummer we missed WP 5.5, I'm sorry I didn't see it earlier, but at least it'll finally get closed.

Let me know what y'all think, it feels like a better approach.

obenland and others added 7 commits July 7, 2020 20:00
The system timezone already comes from PHP site, specifically from
wp.date.setSettings call in wp-includes/script-loader.php

This uses the get_option() to grab the string and setting and surfaces
them to the wp-date package.

This commit adds an additional property called `abbr` which is the short
timezone such as EDT or PST, this is calculated using the PHP date and
time functions.
Converts `-03` to `UTC-3` for timzones like Argentina/Buenos_Aires.

Also updates innline comments.
@obenland
Copy link
Member Author

obenland commented Jul 8, 2020

Nice work @mkaz! This works nicely for me. Feels much better without Moment.

Do the changes in gutenberg_add_date_settings_timezone() need to be ported over into Core in a separate ticket?

@mkaz
Copy link
Member

mkaz commented Jul 8, 2020

Do the changes in gutenberg_add_date_settings_timezone() need to be ported over into Core in a separate ticket?

Yes, but I think that will only done at merge, so wouldn't be until WP 5.6, I can create the ticket for it in Trac. I wanted to wait until we decided this was a good approach or not.

Copy link
Member

@mkaz mkaz left a comment

Choose a reason for hiding this comment

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

It feels a little off approving, since I contributed a chunk of the code, but considering @obenland reviewed my piece and I his, it feels like it should be legit.

We can see if anyone else has any thoughts and merge tomorrow if nothing comes up.

Copy link
Contributor

@draganescu draganescu left a comment

Choose a reason for hiding this comment

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

Tested this locally and now it works as described.

@draganescu draganescu merged commit 05f29fe into master Jul 9, 2020
@draganescu draganescu deleted the add/timezone-tooltip branch July 9, 2020 12:30
@github-actions github-actions bot added this to the Gutenberg 8.6 milestone Jul 9, 2020
@jasmussen
Copy link
Contributor

Thank you Andrei 💯

@mkaz
Copy link
Member

mkaz commented Jul 9, 2020

Associated Trac ticket for core: https://core.trac.wordpress.org/ticket/50624

@blogjunkie
Copy link

Thanks @mkaz for adding this enhancement, but I feel it's still really confusing. Here's a screenshot from a blog that has it's timezone set to PST and the user scheduling the post is in EST. The user is scheduling the post for 5am PST, which is 8am EST in her own timezone. The UI shows 5am and 8am together, which is confusing.

calendar_time1

I'd like to suggest that we simplify this by not showing the user's local time at all. This will avoid confusion of when the post will be published, and negates the need for adding the timezone hint in the first place. Thank you for considering this feedback and suggestion.

@mkaz
Copy link
Member

mkaz commented Sep 11, 2020

I agree its still confusing.

This change is not yet available in WordPress core, it is slated for WP 5.6. So, what you are showing does not have what this PR is trying to fix, what we hope will make it less confusing.

The interface should be only showing the server time and a hint at what that time is, I don't see that hint in your screenshot, for you it should be showing PST (though really it would be PDT because its daylight saving time right now)

However, in testing, it does look like there is a bug and mine is showing my current time but with the label of the server which is incorrect. My local setup is opposite, I'm in PDT and the site is set to EDT.

date-time

I created an issue to address the bug in #25256

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Document Settings Document settings experience [Package] Components /packages/components [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add timezone to Publish date/time for scheduled posts