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

[Autor]

Mensajes

[Clifford]

I appreciate that this is considered a confirmed bug now. I really, really, really hope this gets attention sooner than later. I don't want this to be put on the backburner because less savvy users don't know better and therefore aren't also complaining.

[Luo Yang]

Thanks for the comment, here is an update:
It is set to minor priority for Types plugin version 3.2, but I am not sure when will it be released.

[Clifford]

Looking forward to that!

[Luo Yang]

It is still under development status, nothing update here, can I mark this thread to be "escalated" status?

[Clifford]

As long as I get notified once the update is released... please and thank you.

[Luo Yang]

There isn't any ETA for the update release, it is in the to-do list of Types 3.2, our developers are still working on it.

[Clifford]

Checking back on this, as we're at Types 3.2.7 at this time. Thank you.

[Luo Yang]

I have checked again it in our to-do list, it is still under development status, the "Fix versions" is "Unscheduled", so I am not sure when will it be fixed, but our developers have raised the priority on this issue.

[Clifford]

quarterly check-in on this. I feel like I saw the issue mentioned recently... maybe a blog post or so.

[Luo Yang]

I have checked it in our to-do list again, unfortunately, it is marked as "won't fix" status, see the errata link here:
https://toolset.com/errata/toolset-date-field-stores-local-time-in-the-database-instead-of-utc/

[Clifford]

Oh my. So wrong.

The issue is that DATA IN is always assumed to be the server's time zone (should be and usually is UTC but not always), but the real problem is that data saved lacks time zone.

When you save ONLY a timestamp, there's no time zone context so getting/displaying the value is uncertain. For example, if I'm in Chicago during DST, I pick for an event to occur in Amsterdam at 8pm December 17, 2019 (non-DST), the timestamp won't be reliable... is it Chicago 8pm, Amsterdam 8pm, WP's chosen time zone at 8pm, or UTC 8pm that the timestamp is saved for?

Timestamps on their own aren't fully knowable / able to be converted reliably.

Here's a GIF of The Events Calendar's time zone picker: enlace oculto

When (not if, please!) you implement time zone selection along with date/time selection, make sure to only allow ones in timezone_identifiers_list() (enlace oculto), not WP's time zone picker (allowing manual UTC offsets, which should never be used). You can see enlace oculto for more information on this topic (I wrote the article and developed the plugin).

Even WP 5.3 is adding wp_timezone() to get a DateTimeZone object with the configured time zone: https://core.trac.wordpress.org/changeset/45853

This is because people are learning this is an important issue. We need to be able to use PHP's DateTimeImmutable (which takes DateTimeZone) to be able to do anything reliable with time, even within a single time zone because of DST, which can change from year to year and some locations are doing away with it or changing which offset they use.

You cannot save time inputs (UI) in a way that reliably outputs without time zone context. It's literally the way the world works. This is my primary reason against recommending Toolset.

Please correct your errata and add to your (soon) to-do list. I know it's a decent effort to change, but it's foundational and starting on it now will improve for all the years to come.

[Luo Yang]

Thanks for the details, I forward your comment to our developers, will update here if there is any news.

[Clifford]

Thanks for continuing!

[Luo Yang]

I have checked it with our support team leader, will update here if there is any news.

[Nigel]

Hi Clifford

I just wanted to jump in here to discuss this a little. I've been pushing for improvements in our date field for a long time, but any such updates are competing with other developer priorities, and all we can do is to keep encouraging them to commit to working on this. The main Types developer is receptive and making encouraging noises, but I know he has several other non-trivial tasks that are ahead of this in the queue.

Regarding the issue itself, I see that we have two distinct but linked issues.

First is that we should fix how date-times are currently stored. Second is to explicitly add support for timezones. It may be that the best way to fix one is to adopt two, although I can foresee making improvements to one that don't require two. I don't know, and right now nor does the developer, inasmuch as they need to invest time planning the changes and can't anticipate what their conclusions will be.

As it currently stands, we store date-times as "timestamps", except we don't.

UNIX timestamps are by definition UTC. When users enter date & time into a Types date field we translate this into a timestamp without first converting it to UTC, which results in something that looks a lot like a timestamp in the database, but isn't strictly speaking a timestamp because it's not UTC.

Converting the date & time to UTC first before translating them to a timestamp means that recording the timezone is not strictly required, because the timestamps in the database are true timestamps, which is to say they are UTC, thereby removing any ambiguity arising from server or website or temporary PHP settings.

You then at least know what's required if you want to output the date/time in some particular timezone. (Normally you would be converting the timestamp back to the site timezone setting before outputting.)

But there are, naturally, use cases that require more flexibility, which is where you request for timezone setting comes in. E.g. an event site in the US, the server settings may be east coast but an event in San Francisco will want to display the start time in local time not east coast time. So a timezone setting alongside the date field to specify the timezone that should be used when outputting the field would be helpful.

I'll leave it to the devs to decide what the best storage format would be, but for sure it wouldn't be the serialised array you suggest because that cannot be used for querying and ordering the way a timestamp can.

So, I'm writing this because I want you to know that we do understand why this is a problem, and that we do intend to do something about it, I just can't make any promises about when.