Hi Kim
Unfortunately there is no getting round the fact that our implementation of this is not good.
The original developers of Types (more than a decade ago) didn't implement it correctly, and by the time it began to be questioned years later, it was difficult to come up with a solution for new users that didn't potentially break things for existing users, and we are still in the same position.
So let me explain how it works compared to how it should, so that you can at least make informed choices about how you want to work with this.
Types date fields are stored as "timestamps" (i.e. the number of seconds since 1 Jan 1970).
I say "timestamps" because they are not true timestamps.
True timestamps are—by definition—UTC.
Imagine the timezone setting of a site is New York (currently UTC-4).
Someone enters a post with some date on that site. When that content is stored in the database, the date/time should first be converted to UTC, and then that date/time is converted to a timestamp, which gets stored in the database.
When it comes to display this in a user-friendly date/time format, the timestamp should first be converted from UTC to the correct timezone, then output in the desired format.
But Types doesn't convert to UTC before generating the timestamp for storage (nor "unconvert" from UTC when it comes to displaying it), it just creates a "timestamp" as if it were UTC already.
Note that means when dates are entered (when publishing/editing a post, for example) it is always in the site timezone.
In that sense it doesn't matter that Types doesn't convert the dates to UTC before generating the timestamps (and reverse this when displaying the field), if you put 14 April 16:00 in you will get 14 April 16:00 out, unless you modify the site's timezone setting.
And even though the site timezone might be set to NY, if all of the users were in Spain, say, then it also wouldn't matter.
It can matter when you have users and content across different timezones, but it might not.
If you have a concert that is at 21:00 in NY you would likely want to show site visitors that the concert was at 21:00 regardless of where they were visiting from.
But if you had a webinar that was at 11:00 in NY you would want a site visitor based in London to see that it was at 16:00.
So you may need to customise how the field is output depending on your needs (e.g. creating a shortcode to output the date/time reflecting someone's timezone, allowing for the fact that the "timestamp" is not UTC but is in fact based on the timezone of the site itself).
I hope that at least clarifies how the field works so you can be confident when it comes to handling it.
