Hacker News Reader

Never heard of DST? The authoritative time is constant in the local time zone, but needs to change in UTC twice a year.

This is the exact reason people store time in local time zones.

Also remember the date/time where DST switching occurs is entirely timezone-specific, and it's not necessarily the same pattern every year (as demonstrated with British Columbia).

View on HN

DST works fine with Unix timestamps.

It's the scheduling changes that disrupt DST switch (or something else) need adjusting to. But this is usually planned in advance and everyone would (or at least should...) update their tzdata.

The amount of issues you'll have due to those (comparatively rare) changes cannot even begin to compare to the amount issues you'll have with datetime stored in timezones.

You're suggesting pre-filling future data based on extrapolating current rules (up to an arbitratily unknown high date) instead of using a constant.

I don't really see how that is a good approach in any capacity.

Reply on news.ycombinator.com