Not sure what you mean by passing the timezone as int.

Edited a few words and punctuation marks to make my intent clearer; hope that helps. The idea is to deal with the timezone at render-time, not to pass it around.

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

> Timezones are essentially a UI concept.

Sometimes they are, sometimes they are not.

For example...date+time of birth. The legal date (timezone) is a significant part of this event's time.

> passed around as an int

We're talking about a CSV. CSV don't have ints.

You can use base-10 encoding of the Unix timestamp, or the ISO 8601.

Yes to ALL of that.

I would add that a UI might prompt for a date as well, which of course would be entered using a local time input element based on the the users time zone. But that local time would immediately be converted to an int and passed to an API.