[crote]

It is the 8th of December 2024. I schedule a meeting for the 1st of August 2025 at 09:00 local time.

Your calendar app looks up my timezone. I live in Europe, so at the 1st of August 2025 I'll be observing summer time, so I'll be using CEST - which is UTC+2:00. You convert it to the Unix timestamp 1733658933 and store that.

It is February 2025. The EU passes legislation to abolish summer time.

It is March 2025. Your app gets a timezone file update.

It is the 1st of August 2025. Your app retrieves the timestamp for the meeting, which occurs at 1733658933. You convert it to my local time. I live in Europe, so I'll be using CET, which is UTC+1:00. You convert it to the 1st of August 2025, 08:00 local time.

I am an hour early for my meeting. It is your app's fault. All timestamps converted from CEST are incorrect. You didn't store the original timezone, so you have no way to correct it. You get thousands of angry emails, and everyone abandons your app.

[happytoexplain]

As far as I can tell, the parent is asking the even simpler version of this question, which is "why not just store everything as a Unix timestamp", so even just the obvious example suffices:

I set a 9:00am alarm and then move to a new time zone.

If they meant "why not store everything as a Unix timestamp after pencil-erasing the time zone and replacing it with +0000", then you'd need the more complex example, but then the reference to GPS wouldn't make sense.

[112233]

Or, even simpler, you ask for monthly total, and backend has no idea what "monthly" means, because it started/ended at undetermined local hour that has been discarded when converting to "utc"