> You store the local time and timezone. You show the value in whatever timezone the user configured the application.

Because local time is ambiguous. During DST changes local time can mean that it happens twice. Your calendar would have to show 4 AM twice for instance and if you want to make an appointment there you would have to select which one you actually mean, thus UTC + local time.

But granted, it does not happen often that people schedule appointments during DST switches, but certain professions have to so certain people already have to live with that.

> If you store both the Unix timestamp, the local time and the timezone, you have too much information.

Nope. That is incorrect. If I store local time only + timezone and someone sets a date during that transition window it's ambiguous. If I store the date in UTC only and remember the timezone that date was intended for I will not be able to account for changes in the timezone. For instance the legislation of the country could deactivate or change DST settings (which is not uncommon). In that case the timezone information of my operating system will change again and my appointment will move without my consent.

If I store both I can see if they are still in sync and if not, prefer the local time and rebase as necessary.

Oh, I see what you're referring to.

Yes, storing the local time and the timezone is not exactly what's enough, all that time I was thinking about the PostgreSQL timestamp with time zone type, which is preferable to use vs storing the Unix timestamp.

I guess we've been talking past each other, with me being the main culpable :)

Why not store the Unix timestamp and the timezone that was set when created? Then you can just as easily determine what the original local time was and also convert to whatever the current local time is.

And you save yourself the misery of endless conversion when trying to compare anything internally.