You apply your local timezone to the UTC value. There is no reason to store a timezone with it.
The weird thing is you need to always apply the timezone when reading, and un-apply it when writing. This needs to happen at the lowest level of access.
I know how you can convert UTC to local time. The problem is that without timezone info, some system can parse the UTC time AS local time. There is no reason for most date parsing libraries to assume that they are always being fed UTC times and from what I've seen, most date parsing libraries assume timestamps without timezones are in local time unless told otherwise. You can avoid all of this by always storing and passing around timestamps with timezones.
Don't use that for future appointment times though. When someone books a 9am appointment in 6 months they want that at 9am of whatever timezone it will be at that time and location.
Don't use it for past times either without thinking what you'll use it for. If you want to generate reports of historical data in the user's timezone at the time of the event, you can't convert back just knowing their current timezone. [0]
I find UTC painful from a West Coast perspective, too. -8 is 1/3 of a day, and it puts the UTC date rollover at either 4pm or 5pm depending on DST. It genuinely makes solving problems using logs twice as difficult, as a lot of problems strangely tend to happen around that time.
I've been reading UTC times from all over the world for 20 years ... I've never had any issues. You only have to convert once: the time of the incident.
When you work on a consumer app, it's often important to correlate incident events to real clock time, especially if an external event caused the incident. It's much easier when your logs match your clock.
Speaking from my 30 years of experience reading logs. :)
> especially if an external event caused the incident
this has a trivial solution - you convert the times of external events to UTC as well.
for example, the Super Bowl is going to cause a spike in traffic. the Super Bowl this year had its kickoff at 23:30 UTC.
> It's much easier when your logs match your clock.
part of the point of UTC is that "your clock" shouldn't be viewed as privileged or universal. because other people have different clocks.
what you're doing with this Arizona trick is basically inventing "UTC, but slightly different and more convenient for me specifically"
you get used to doing this "they usually match, except 4 months of the year they're off-by-one" trick. but then you're on a business trip to New York, and now you have to remember that it's either a 2 or 3 hour difference, depending on the time of year.
or, you hire a remote engineer in Adelaide, which is UTC+9:30 or UTC+10:30 depending on DST. do you want that engineer to be doing half-hour addition & subtraction in their head in order to correlate log timestamps in Arizona time with their local clock? also keep in mind they're in the southern hemisphere, so they have "summer time" reversed from the northern hemisphere, and they do 6 months on and 6 months off instead of 8 and 4 as the US does [0].
every desktop environment I know of supports adding a second clock with a different timezone to the system tray. on my work machines I have one for my local time, and one for UTC. it's very easy to look at the latter when I want to know "what's the current time as far as my servers are concerned".
I am a strong believer in not storing logs, as they tend not to be useful after a few minutes, other than security logs. But I do find real time logs to be useful information for incident response.
Use UTC for everything, except when displaying then convert at the last moment in UI code
The U in UTC is for Universal.