if you need context, e.g. location, you can still save it in another field and you will be able to correctly display localized time at any point given the universal timestamp and the current location. Or you can save properly localized and tz-aware time, I just find timestamps safer from pitfalls.
> if you need context, e.g. location, you can still save it in another field
No. Say I have a database with a bunch of timestamps for future events. I calculate the time of those events with my current idea of local time (because my customer or because legal requirements require me to do something at a specific local time), convert to GMT, and store as a timestamp in my database.
In 2024, California decides to no longer observe Daylight Savings Time. All of those current timestamps no longer happen at the proper time in the newer version of America/Los_Angeles.
So there's a big pitfall here, in that the relation between localized time and UTC timestamp changes.
Sure, you and others like you make pretty valid points. I believe we are talking about different use cases, hence the confusion. I was thinking of my most common use case of archiving events, usually experimental data, with a non ambiguous time reference.
If you need to schedule future events it gets obviously a lot more complicated, you don't need a timestamp you need local time and you need it to be robust to future changes in timezones, DSTs, politics.
Basically, it's important to recognize what you're actually measuring/capturing and store something maximally equivalent to that. Conversions may render figuring things out later impossible or very difficult.
If you care about a past moment in time as reported by GPS or a computer clock-- use a UTC timestamp.
If you care about a future time delineated by a precise interval from now-- use a UTC timestamp.
If you care about a future time expected to be delineated in a specific time zone, use a timestamp in local time and note the zone.
If you care about a future time in a customer's time zone no matter where they may be, store the time in an unspecified local time and the customer for whom the time applies. Etc.
You seem to make a contradicting statement here with what you wrote in the sibling comment, no? timezone information are influenced by political means, whereas localization (lat/long) information is not. UTC timestamp + localization seem more correct to me.
The semantics of "time X at point Y" are different from "time X in time zone Z". Sometimes the former may indeed be what you want, but it's uncommon for the user to be providing precise location information for a point in time far in the future. If you're told "time X, Eastern standard time", then the semantically correct thing to do is to not guess a point in space, but instead preserve the time zone as provided.
This line of thinking is how we end up with nonsensical UX like having to select "America/Los Angeles" to get US Pacific time. There are many use cases for datetimes and timezones, not all of them need a location and in some cases it's incorrect or misleading to include a location. You could certainly use a UTC timestamp and coordinates in your application but that doesn't work for many other use cases.
