Hacker News Reader

Comment by aetherspawn | Hacker News Reader

Suggestion, design your app to not be time zone dependant if at all possible.

For example, store dates in UTC and render instantaneously in current time zone.

That only works for past events, not future ones. Converting to UTC is lossy so rendering timestamps correctly in the future becomes problematic with DST/TZ rule changes.

Really depends on what you want to do. If it's something like "set the date at which new system behavior x becomes effective", UTC is perfectly fine; for scheduling a meeting, not so much.

> Converting to UTC is lossy

How so? UTC is a constant point in time. The difficulty lies in representing the value correctly, but the point in time is unchanged.

Unlike what sibling comment mentioned, if an appointment is scheduled at 1739287704987, the value will be the same regardless of where and when it's accessed from.

Yes, but they're saying that only works for past events. If you book a dentist appointment in the future using a timestamp, but then the tzdb rules change, you'll wind up with an unexpected result. (Because the civil time will be different and people usually book appointments based on civil time.)

Touché. We should have stuck with Swatch Internet Time

https://en.wikipedia.org/wiki/Swatch_Internet_Time

> and render instantaneously in current time zone

And for that you need to have a timezone-change event, if you don't want to poll the current system timezone.

For timestamps, which are considered fixed points in time, yeah. Dates and times are different. If you block off 12-1pm for lunch in your calendar every day, the actual timestamp of that event might change if you fly elsewhere and set it to use the local timezone automatically. Same with holidays and birthdays.

Reply on news.ycombinator.com