undefined | Better HN

0 pointswim1y ago0 comments

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.

0 comments

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

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

sureIy1y ago

Touché. We should have stuck with Swatch Internet Time

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

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

j / k navigate · click thread line to collapse

0 comments

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

burntsushi1y ago

sureIy1y ago

Touché. We should have stuck with Swatch Internet Time

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

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

j / k navigate · click thread line to collapse