3 ms·

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.

mschuster91 2y ago
> 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.
wim 2y ago
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.
- lxgr 2y ago
  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.
- sureIy 2y ago
  > 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.
  - burntsushi 2y ago
    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.)
    - sureIy 2y ago
      Touché. We should have stuck with Swatch Internet Time https://en.wikipedia.org/wiki/Swatch_Internet_Time https://en.wikipedia.org/wiki/Swatch_Internet_Time
iforgot22 2y ago
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.

mschuster91 2y ago

> 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.

wim 2y ago

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.

lxgr 2y ago
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.
sureIy 2y ago
> 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.
- burntsushi 2y ago
  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.)
  - sureIy 2y ago
    Touché. We should have stuck with Swatch Internet Time https://en.wikipedia.org/wiki/Swatch_Internet_Time https://en.wikipedia.org/wiki/Swatch_Internet_Time

iforgot22 2y ago

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.