Yes, but that’s handled by the user’s software when they access or edit the appointment. All calendaring software I know uses UTC internally like that, where the tz adjustments (including daylight savings rules - and historical too! are the responsibility of the topmost, user-facing parts of the system. I don’t know why I’m getting downvoted for saying this - am I missing something?
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. Further, what is displayed depends on the viewer's location (because daylight savings times change differently based on location/date). IOW, the time of the meeting occurs on TWO UTC times, not one. You can't just store UTC and be done with it. You need the originating timezone too. In other cases you may need the date the item was created as well.
More sophisticated calendar software will take into account holidays or use offsets from month start/end. i.e. "we'll have a meeting at 9:00pm Tokyo time, every last business day of each month".
> 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
> 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).
