Hey @colin.cole,
Sorry, this is a known issue and frankly a weakness in our current DateTime implementation 
I agree with you that this is not ideal, and I’ve previously tried to convince the devs to change this behavior, but it is not something they want to change right now. I’m sorry. It could be a feature request here, or as a workaround, you can make another field to store the time zone info with your own time zone strings.
To be clear, that means you would need two separate fields:
- The time itself (probably stored as a JSON object that you define that would have hh:mm data, rather than our native datetime field data)
- Another plaintext field acting as a dropdown where your editors could select one of several IANA time zone strings, like “America/Los_Angeles” or “Etc/UTC” or “Europe/Brussels” for example
Your frontend would then query these two fields and then display them accordingly. Unfortunately the UI of #1 (time entry) won’t be as nice unless you add some custom code (like via a plugin and a custom form field), or just provide good help text for what to enter.
If it would help, I can make you an example plugin that would do something like this?
Alternatively, the super-simple version (that would have no validation and can’t be easily parsed) would just to be have a plaintext field where your editors could enter the time and zone as a regular plaintext string, like “17:00 CEST”.
I’m sorry for the hassle, and please let me know if an example plugin would help.