[Escalado a 2º nivel] Time stamp custom field needs to support time zone as well

[Autor]

Mensajes

[Clifford]

Re: https://toolset.com/forums/topic/timestamp-custom-field-not-intuitive-its-in-utc-and-views-incorrect-output/ (allows me to try to enter a new reply but errors out saying the topic is closed)

Hi. Came up against this again... Sorry I didn't get back to you earlier. I searched the forums and found my own thread ?

I created a new datepicker+timepicker field and set it to Sept 6 at noon. The database saved to Sept 6 noon UTC

Can you confirm that the datetime is always set to a timestamp in UTC time zone? Or is it in the server's time zone (which is always recommended to be UTC but may not be)?

If it's always UTC, that'd be more reliable at least... Although adding a time zone picker would be the most accurate (from enlace oculto, not WP's because that has "fake" time zones like manual UTC offsets, which PHP won't play nice with)

Please advise how I can intercept the saving of any/every datetime field (wp-admin or Toolset Forms) to enforce saving the correct timestamp, such as a filter to always save timestamps in a specific time zone, like

America/Chicago

or

Europe/Amsterdam

[Clifford]

I also noticed using a datepicker without time option saves the UTC timestamp of midnight that day. For example, if I select Sept 5 in the UI, I get 1536105600. Therefore, if you do add a time zone picker to the datetime picker, please make sure it appears even if the Time option is disabled.

Sept 5 midnight UTC is not the correct time stamp for our site's Chicago time zone (Sept 5 midnight Chicago)

[Luo Yang]

Hello,

For the question:
Please advise how I can intercept the saving of any/every datetime field (wp-admin or Toolset Forms)

I suggest you try the wordpress built-in action hook "added_post_meta" and "updated_post_meta", see the example:
https://wordpress.stackexchange.com/questions/16835/how-to-hook-update-post-meta-and-delete-post-meta?answertab=active#tab-top

More help:
https://codex.wordpress.org/Plugin_API/Action_Reference/updated_(meta_type)_meta
https://codex.wordpress.org/Plugin_API/Action_Reference/added_(meta_type)_meta

[Clifford]

I thought of that but couldn't that cause confusion with the way Types reads the stored data?

For example, if I intercept it on the way in, then Types reads a timestamp in a time zone different from the server's time zone (usually UTC) and could end up displaying the wrong date in the UI.

Basically, I'd have to intercept it and do timestamp conversions from one time zone to another on the way in and on the way out (reading). And isn't it just more reliable/robust/better UI to just add a time zone picker along with the datepicker because then all date fields are handled properly (in case a field got renamed or we forgot to add one to the list to intercept) and the database has accurate timestamps, too.

[Clifford]

Interestingly, using "e" in a View's date formatting output for a Types datetime field displays WordPress' time zone yet the actual datetime is UTC.

[Luo Yang]

Q1) I thought of that but couldn't that cause confusion with the way Types reads the stored data?
Types plugin read the time-stamp value of custom field, output it the time-zone depends on your website settings:
Dashboard-> Settings-> General, option "Timezone", see our document:
https://toolset.com/documentation/customizing-sites-using-php/functions/#date

Q2) And isn't it just more reliable/robust/better UI to just add a time zone picker along with the datepicker
There isn't such a built-in feature within Types plugin, if you agree, we can take it as a feature request, our developers will evaluate it.

[Clifford]

Q1: Your answer is not what I've experienced:
The following shortcode has "e" in the date format, which displays the time zone:

[types field='session-start' style='text' format='F j, Y, g:i a e'][/types]

The output from this is that everything other than the "e" matches the server's time zone (UTC), which is the timestamp stored in the database, but then the "e" displays the WP site setting's time zone (Europe/Amsterdam in this site's case, which is UTC+2 right now).

To be clear, if the timestamp went in as UTC (since the datetime field doesn't support time zones) for Sept 7 2018 at 17:30, that is exactly what will be displayed via the shortcode (in the specified format)... except "e" will append "Europe/Amsterdam" to it, not "UTC", which would be accurate.

So are you saying this is not what you're experiencing, that on your site the shortcode will convert the display of time to be in the time zone from WP's General Settings?

Q2: YES PLEASE do take this as a thorough request for adding a time zone picker to the datetime picker (even if the Show Time option is not checked, since midnight on a specific date is also time zone specific).

Thank you.

[Luo Yang]

I assume you are going to display the time zone value like this: UTC+2:00

Please try to modify your codes as below and test again:

[types field='session-start' style='text' format='e P'][/types]

More help:
enlace oculto
P Difference to Greenwich time (GMT) with colon between hours and minutes (added in PHP 5.1.3) Example: +02:00

[Clifford]

No. I want "e"...

From the PHP documentation:

e	Timezone identifier (added in PHP 5.1.0)	Examples: UTC, GMT, Atlantic/Azores

I want "some datetime Europe/Amsterdam", not "some datetime UTC+2"

I've tried to provide ample reasoning for why "Time Zone" needs to be added to the datepicker field and to the Toolset APIs (such as displaying a date via shortcode). I'm not sure how much more I can do to convince you, but I'll do whatever you need me to because it'll fix a lot of things and make Toolset a more robust solution for datetime-related parts of projects.

[Luo Yang]

Here is a test site:
enlace oculto

1) WordPress General Settings, option "Timezone" choose option "Amsterdam"
enlace oculto
username/password: xgren/111111

2) Test the same shortcode as you mentioned above
enlace oculto

[types field='session-start' style='text' format='F j, Y, g:i a e'][/types]

See the result in front-end:
enlace oculto

I can get the timezone of General Settings without any problem:

September 14, 2018, 12:00 am Europe/Amsterdam

Is there any step missing?

For this question: "Time Zone" needs to be added to the datepicker field, as I mentioned above, there isn't such a built-in feature within Types custom date field, it needs a feature request.

[Clifford]

Good idea to start a test site 🙂

This:

[types field='session-start' style='text' format='F j, Y, g:i a e'][/types]

Displays:

September 14, 2018, 12:00 am Europe/Amsterdam

Midnight display is correct because it was a date field without a time option.

However, the issue is the database entry. I updated enlace oculto to have this content:

Text: [types field='session-start' style='text' format='F j, Y, g:i a e'][/types]
Timestamp: [types field='session-start' style='text' format='U'][/types]

This displays:

1536883200

Putting that into enlace oculto confirms it is midnight UTC (your server's time zone), not midnight Amsterdam (WP's time zone).

Technical points:
- using PHP's date() will use the server's time zone, which is usually (should be) UTC, but it could be different, and it is open to manipulation by poorly-coded plugins that may utilize date_default_timezone_set() (poorly coded if they don't cleanup after themselves or affect your plugin unintentionally)
- because the WP time zone can change at any time, saving all the timestamps in the database in the time zone from WP's settings is ripe for potential trouble
- therefore the field itself should have a time zone option/field, just like date has optional "time" option/field. The time zone field should not be optional because defaulting to midnight is still time zone dependent.
- make sure the time zone selection list defaults to WP's chosen time zone if it's a valid one from timezone_identifiers_list() (see enlace oculto, enlace oculto">code and article written by me)

Alternative solutions:
- PHP DateTime class is the best but only works with valid time zones, and WP pollutes with manual UTC offsets (which, IMO, are only ever chosen by users out of confusion and WP should remove these)
- or you could use strtotime() but you wouldn't do

strtotime( '2018-09-14' )

, instead you would also pass the time zone string:

strtotime( '2018-09-14 Europe/Amsterdam' )

and that would be an accurate timestamp saved to the database (could even support WP's manual UTC offset time zones but this is terrible)
- Even better, instead of saving timestamps, save as a serialized array containing the date, time, and time zone:

['date' => '2018-09-14', 'time' => '17:30:00', 'time_zone' => 'Europe/Amsterdam' ]

- Doing it this way will have many benefits: could build multi-time zone apps (calendar) and support people outside of the site's own time zone (site is in Chicago, users are across all of the USA); human-readable database entries; your shortcode/function could add a time zone parameter, which would allow for converting from the saved time to any other valid time zone (if not set, would use the field's time zone value, of course)

I'm happy to help more if needed. My goal is that your product is made better by handling "time" correctly (fixing the bug) and hopefully also making it more robust (features).

[Luo Yang]

Thanks for the details, we can handle the questions one by one:
Q) Putting that into enlace oculto confirms it is midnight UTC (your server's time zone), not midnight Amsterdam (WP's time zone).

Yes, you are right, the time stamp value is "1536883200", it is midnight UTC, are you expecting the midnight Amsterdam?
and the value should be "1536876000"
enlace oculto

Can you confirm it? thanks

[Clifford]

Yes, exactly.

See that midnight Sept 14 Amsterdam is actually Sept 13 UTC.

[Luo Yang]

Thanks for the confirmation, I have escalated to our 2nd tier supporters, will update here if there is anything news.

[Luo Yang]

Here is the feedback from our 2nd tier supporters:
It is a known issue, our developers are working on it, but I am not sure when will fix it, I will keep you update if there is anything news.