3 ms·
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 rul
by 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 agoReally 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 agoYes, 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 agoTouché. We should have stuck with Swatch Internet Time https://en.wikipedia.org/wiki/Swatch_Internet_Time https://en.wikipedia.org/wiki/Swatch_Internet_Time