Adding to this, if you are dealing with dates in JavaScript specifically I recommend going further and doing all business logic with the UTC timestamp stored as a number / unix epoch, and only doing `new Date(timestamp)` when you need it in local time, like right before rendering on the page or something as you mentioned.

It obviously depends on your use case but I find most time operations are often easier to deal with as pure mathematical operations. I will reach for Date when I need to deal with weird stuff like the day of the week but having burned through so many footguns with what I consider the worst DateTime API I have ever dealt with in any language, I will do anything I can to avoid using it.

Some libraries like date-fns can help here, but can't always bring in new deps easily. I hope the new temporal API fixes things.

I was thinking like that before, however now I think it's overkill. Millisecond timestamps are hard to read, they are stored as "bigint" in Postgres, which makes it sometimes annoying. What I prefer now is to use the date object, but remember that it's only UTC (and the machine where the code runs should be in UTC time too). It goes well with Postgres Timestamp+TZ field, and it's much more readable.

I have always followed the same, but also found calendar events are a good carve out to this.

The user doesn't care about the timezone change yesterday (and shouldn't..), they just need to see their meeting at 10am.

It is a good carve out, but it means you have to be careful.

For example, in my work, we handle appointment data, and we've gotten appointments sent to us from an upstream provider scheduled for non-existent local timestamps. (E.g., 2:30am in the middle of a spring-forward jump. That timestamp doesn't exist. Also in the fallback, where that timestamp is ambiguous.)

Even Google Calendar chokes on certain appointment times.

It's just not DST though. What if the user moves to a different country? Their 10am US meeting should probably update to the local timezone.