When you store the time of a future event (like a reminder for 1 year from now), and integer since epoch does not work.
Your event is initially in the user's timezone (e.g. 10am 20th of June 2024 in France), if you store it as a number then you are fixing the exact second at which it will happen.
However, if the timezone in question has some changes you didn't anticipate (new law voted, no more summer time), then you will either be triggering your event 1h before (e.g. 9am instead of 10am) which is probably not what your user wanted, or you'll have to recompute all your timestamps to take that change into account.
Instead, you could store rhe event with the target timezone, and let your datetime library that is up to date figure out next year.
> However, if the timezone in question has some changes you didn't anticipate (new law voted, no more summer time), then you will either be triggering your event 1h before (e.g. 9am instead of 10am) which is probably not what your user wanted, or you'll have to recompute all your timestamps to take that change into account.
This is a really interesting scenario that I hadn't considered at all. You're totally right; this approach breaks down there.
Off the top of my head, it looks like this scenario would require manual action either way, though. Either it's an update of the packaged datetime library to incorporate this new regulation, or it's a database migration to update the timestamps for affected users.
The same goes for "times this business is open" to store "9am-4pm on weekdays" you probably want to store almost exactly that string, rather than some ints. Generally speaking, dates stored as "ints" are mostly good for timestamps of events that have already happened (or even more precisely events that your application generated/logged live). Other use cases may be more rooted in the "human" dates than in absolute time
Your event is initially in the user's timezone (e.g. 10am 20th of June 2024 in France), if you store it as a number then you are fixing the exact second at which it will happen. However, if the timezone in question has some changes you didn't anticipate (new law voted, no more summer time), then you will either be triggering your event 1h before (e.g. 9am instead of 10am) which is probably not what your user wanted, or you'll have to recompute all your timestamps to take that change into account.
Instead, you could store rhe event with the target timezone, and let your datetime library that is up to date figure out next year.