Hacker News new | ask | show | jobs
by DaiPlusPlus 307 days ago
> If you set a recurring meeting, every Friday at 10:00AM, New York time, the time in UTC varies (either 14:00 UTC or 15:00 UTC) depending on the date.

> You can't just store UTC and be done with it

Right; though there are different approaches to handling this in software; one approach is to create concrete (as opposed to virtual) records for each occurrence of the recurring pattern[1] so that any other software concerned with viewing/handling those events can be given precomputed UTC values and not have to worry about local user settings or parsing recurrence patterns.

...whereas another approach, which you mentioned, is to treat those occurrences as virtual-events derived from the (local-to-the-user) recurrence pattern, which requires the software to retain full timezone info (not just UTC offset) for the pattern, which increases software complexity (not to put it down; I'm simply saying that each approach has its benefits and drawbacks).

[1] For practical reasons, systems like these only generate concrete records for, say, 1-2 years out into the future (and retain the ability to mass-update their individual occurrence times when the user's pattern specification changes).

So what you say is true - and demonstrates that my desire for UTC-only systems is unworkable... but only for this particular scenario.

Fun-fact: I have a legit copy the four specs in ISO 8601 ($500, ouch!) , and buried in ISO 8601-2:2019 section 7.3.1 there's an admission of inadequacy:

> Representations of local time of day as defined below make no provisions to prevent ambiguities in expressions that result from discontinuities in the local time scale (e.g. daylight-saving time)

...whereas if everyone used UTC everywhere all-the-time for everything (i.e. ban daylight savings time!) then this problem wouldn't exist and my original point that started this whole thread remains true :3

1 comments

> one approach is to create concrete (as opposed to virtual) records for each occurrence of the recurring pattern[1] so that any other software concerned with viewing/handling those events can be given precomputed UTC values and not have to worry about local user settings or parsing recurrence patterns.

This approach assumes that concrete records can actually be computed by the time the series is created. That may not be feasible. Some countries pass their DST policy on very short notice (i.e., days or months rather than years).