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.
