[Resolved] Can a date/time field be modified based on the user's timezone?

[Author]

Posts

[aaronM-9]

I am creating an events function in my website and I would like events to display the start/end times in the user's local time based on their timezone. My question is twofold:

1) Can I modify the value of the date/time after the form has been submitted to be in some universal timezone, like GMT, based on the user's timezone as set in their WordPress account? For example, if I'm in the eastern US timezone and I enter noon, it would actually store 4pm in the database.
2) When displaying the post (either in a view or a layout), can Toolset change the time based on the user's timezone as set in their account? Using the same example as above, a user in the pacific timezone would see 9am.

I couldn't find much on this topic except that Toolset will always store the Unix time exactly as the user inputs it. Thanks for any help.

- Aaron

[Nigel]

Hi Aaron

We don't really do this right, but for legacy reasons there is no way we could ever change it because of the potential number of sites that might be affected.

When you enter a date and time in a Types date field we convert it to a UNIX timestamp. UNIX timestamps are, by definition, UTC (aka GMT).

To do that right means that, for a site which is based in US EST for example, you would first adjust for the time difference between EST and GMT, and then convert to a UTC timestamp.

To display date/times you would do the reverse.

However, we don't do that, we omit converting from EST to GMT, we convert straight to a timestamp without adjusting the timezone first, and when displaying such a field we likewise just go straight from UTC timestamp to a formatted time and date, ignoring the timezone difference.

So, the time and date that are displayed in the field on backend post edit screens or when outputting the field with shortcodes are always based on the local settings for the site (per its timezone settings).

How deep you need to go in terms of providing local times based upon the user's own timezone settings depends on whether you actually need to modify how the dates are stored in the database and displayed on the post edit screen, or whether you only really need to concern yourself with how dates are displayed when shown on the front-end via a template, for example.

The latter can be fixed fairly simply using a custom shortcode, bearing in mind how the dates are stored as I described above.

It's not just us. I happened to notice earlier this morning that there is an audit of WP's date functions because they themselves are problematic, as described here: hidden link

Note at the very bottom of the diagram on that page it shows the PHP functions you should familiarise yourself with if you want to write a custom shortcode for this, for example.

(The queue is very busy at the moment, so if you need help writing custom code it will be a while before I can help.)

[aaronM-9]

Hi Nigel,

Thanks for that explanation. Still sifting through my options here. In a related question, can you tell me if Toolset Maps can use the Time Zone API or can it only use the Geocoding API and, if so, how I would tap into that data? I'm asking because I would like to set the user's (or the event's) timezone the same way I set the address (by pulling information from the maps API when they select their location). Then I would use custom code to modify the timestamp on certain posts.

- Aaron

[aaronM-9]

PS: This is just an idea - I'm probably way over-simplifying things - but maybe one way you guys could build this improvement into your offering would be to create a second date format (so in the field group editor there would be two date options). The second date option would automatically adjust based on the user's timezone and sites that were built using the original date option wouldn't be affected. Then customers could migrate to the new method at-will and existing sites wouldn't be affected.

- Aaron

[Nigel]

Hi Aaron

Maps doesn't use the timezone API, no, you would have to set that up yourself as described in the Google docs: hidden link

From that it looks like you need to pass the lat/lon coordinates to the API and it will return the timezone.

Views stores a cache of lat/lon coordinates for each address in the wp_options table with a key of 'toolset_maps_address_coordinates'. Starting with the address string from your address field you can find the corresponding coordinates from that Views cache.

(An alternate method would be to piggy-back on the Google geocoding API call made when entering an address into an address field. We only save the formatted address (provided by Google) and the coordinates, but there is other data available (e.g. postcode) which is not stored, but which can be accessed at the same time. I described doing that in another thread (hidden link) a long time ago, and you could use a similar technique to get the coordinates and use them to access the timezone API straight away.)

I don't see us implementing this, it hasn't been requested before, and depends on all users entering an address to lookup their timezone, before making any adjustments to how times and dates are displayed.

Our implementation of date fields is flawed, as described above, but it is consistently flawed and has been the same way for years, so can be predictably handled.

Currently the times are based on the site settings, e.g. a French site displaying events in France will show the event time in local time, which makes sense, even if you are looking at the site from Dubai. I think any variations on this need to be handled by clients in a way that suits their own needs. I just wish we'd implemented the date field correctly in the first place.

[aaronM-9]

Hi Nigel,

Thanks again for all the help. And so you know, I know exactly which geocoding post you are talking about - that was tremendously helpful to me earlier in the site development. I have managed to add on to what you originally posted with a call to the timezone API to get the timezone based on the event's location so I think I'm off to the races for now. Next step will be to make the conversion into the database and then again when other users are viewing the post.

- Aaron