-
Notifications
You must be signed in to change notification settings - Fork 4
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
Button Expiry timezone is confused #624
Comments
There seems to be some history and updates here, continuing here, here and finally here. I think a general summary is that moment.js was introduced to localise the dateTimePicker component, but then removed as it was causing too many issues. My own thoughts are that all times should be running to "WordPress time" - whatever the site timezone is in site settings - akin to "ship time". Introducing local times quickly gets confusing. To add to these changes, in the Button with Expiry block plugin, the I've now changed the Button with Expiry block to calculate in New York time, the same as what the WordPress LFE site is set too. Ship time. The dateTimePicker is as the component is now distributed using the site time. Which for LFE is currently set to New York (EST). After my update, when I see the dateTimePicker (using Chrome or Safari), it displays as EST (I am in UTC London). When I use BrowserStack it also displays dateTimePicker in EST, even though the Geo-IP puts me in Netherlands and Google locate thinks I'm in Tbilisi (!). I think this confirms that the dateTimePicker is not geolocating based on the user timezone. Now if I set an expiry date and time, it syncs with New York time, here's a video showing live clock, editor and frontend with the frontend refreshing after the time and the button now being expired to the second. |
The two screenshots in your last comment show different times... is that because you snapped them exactly one hour apart? Or are they getting affected by their location? |
Nice spot. I just checked browser stack and that time does indeed change to be the current Hour and Minute based on the location, but this doesn't affect the timezone. In the default for the block, the following is set:
The JS Date.now() probably needs NYC timezone attached to it... |
Setting things to NYC-time?? You're living in the past man!! I set my watch to Beijing time now... America is dead!! |
The block now pulls in the sites timezone to make its time decisions, so if the sites timezone is updated the block will reflect that. When adding a button it now puts in the current time from sites timezone. i.e. It's 14:01 in London now where I am, 09:01 in New York, when I insert a button it displays as 09:01. I removed the previous default of "add 24 hours on to (current) users time" as I couldn't really see it being useful and it just adds complexity. |
A couple of weird things:
|
This has been closed with the merge operation. |
This seems to be broken again. When I open this post in my browser it shows this: But when I open it in a browserstack browser in India it shows this: So not showing EST time in either case. |
this should be good now |
* Upgradeing to WP 5.9 * Remove defunct wp-cli.yml file * Fix: Trying to get property 'post_parent' of non-object * Make node nvrmc consistent with Lando local dev * Updating wp-config layout to better distinguish between local dev and prod * Updating NPM packages * Fix: Upgrade Buttons with Expiry to work with WordPress 5.9 * Updating Image Box Block * Updating Track Grid block * Fix: Revert imagemin upgrade to match gulpfile * Fix: Reverting change to lfe_get_event_parent_id as cannot reproduce PHP error * Fix: Revert imagemin upgrade to match gulpfile * Reset package files to diagnose build error * fix expiry timing (#624) * fix timezone issue (#624) * improve logic for expiry of buttons; accommodate existing buttons * simplify code a bit more * change "View..." buttons in calendar to links (#677) * Upgrade WP to 5.9.1 * made the past events link bolder and larger * fix issue with setting country for KCDs Co-authored-by: James Hunt <[email protected]>
Before the WP Upgrade, things worked like this:
On my computer, chrome: I create a post and set the expiry date to one minute away in my local time. It correctly expires a minute later.
On Browserstack's Windows computer running chrome in Australia: I open the post and it shows the expiry time in PT, so that's neither my local timezone nor the computer's.
On Browserstack on MacOS running chrome in Australia: I open the post and it shows the expiry time in the Australia time zone.
After the WP Upgrade, things work like this:
On my computer, chrome: I create a post and set the expiry date to one minute away in my local time. It correctly expires a minute later. It shows the timezone as "EST" after the time for some reason.
On Browserstack's Windows computer running chrome in Australia: I open the post and it shows the expiry time in PT, so that's neither my local timezone nor the computer's.
On Browserstack on MacOS running chrome in Australia: I open the post and it shows the expiry time in the Australia time zone.
So the only change in the WP upgrade is the use of "EST" after the time. I assume the underlying issue is a bug that should be fixed in future versions.
Open question: The control in question is the
DateTimePicker
from@wordpress/components
. Is that the correct control to be using for this or is it deprecated or something?The text was updated successfully, but these errors were encountered: