I'd argue that setting a specific datestamp and time for DST would mean that you expected to meet at that specific time and date as per DST. If the clocks changed you'd be out of luck (that's where I'd argue you'd use a non-specified timezone for a meeting that re-occurs at 10:05 regardless of say PDT or PST).
But if this was an issue with a recurring meeting, then when the clocks changed someone would be out an hour because they had specifically booked with DST in mind (note: this is more useful than you think - being in non-DST countries and having scheduled meetings in DST based countries, a lot of cal applications get this wrong when what I actually want is for that DST scheduled meeting to now be reflected in my calendar on the fact they've switched to ST in their time zone - so shifted an hour.). But I feel this is something that would be for people who need to take advantage of this. And, more often than not, is a recurring meeting issue when DST/ST changes occur. Daryl. On Tue, Jan 17, 2023 at 3:54 AM Robert Horn <rjh...@panix.com> wrote: > > Ihor Radchenko <yanta...@posteo.net> writes: > > > Robert Horn <rjh...@panix.com> writes: > > > >>> 1. Time (YYYY-MM-DD HH:MM) not continuous and may change arbitrarily at > >>> certain times a year or in future or in the past: > >>> - DST transitions are not stable and change from year to year > >>> according to strange rules that may involve Julian dates or > >>> counting weekdays > >>> - DST transition rules may change over time > >>> - The new year day itself is not necessarily fixed (England > >>> - Julian/Gregorian transitions happened at different times in > >>> different countries > >> > >> Note that as a result "time when it happened" has different rules than > >> "future time when it is scheduled". There are lots of other times that > are > >> scheduled as "future local time, subject to changing DST rules". This > >> is particularly tricky for repeating times for regularly scheduled > events. > > > > Not really. Countries may change DST at any moment in future. Or decide > > to switch calendars (consider countries near the day transition line). > > > > And "past local time, according to the DST rules in effect at the time" > > is also an option that might be useful in certain scenarios. > > > > The issue is clarity of the expected rules for the format. If I > schedule a meeting for 10:05 DST, but the rules change so that it is not > DST at that location at that time in the future, what is the expected > interpretation? It could be: > > a) the meeting should be at 10:05 ST, because the intent was to meet at > 10AM in the then local time. > > b) the meeting should be at 11:05 ST, because the time was chosen to > correspond to a particular sun angle. > > Getting the rules and explanation clear is the issue. It's a mistake > that a great many people make with scheduling meetings. Those two > behaviors need different encodings because they behave differently. > > -- > Robert Horn > rjh...@alum.mit.edu >
