Which would have the exact same problem as UTC.

For most use cases when a users enter a datetime in the future, they do not care about how many seconds from 1970-01-01 that point is, they care that it occurs at exactly 12:30 on that particular day.

Well, yes, but you really need to add some information to it. The last system I worked on that really needed dates for transactions and reporting stored: local time, local time zone, local offset from UTC at time of event, and UTC time stamp.

Its amazing how complicated your life can get when reporting across time zones and then mixing that with legal requirements for some reporting.

Also, time zone id and local time is insufficient unless you keep reference tables that can calculate what offset was in effect at the time of the event. Save the trouble and just record it along with the time stamp.

It's not. The lede is "store intended time w/ TZ, and also compute and recompute UTC timestamps as needed".

And get the same problems, plus the new one, leap seconds (timestamps ignore them).