Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Daryl Manning <daryl@wakatara.com>]

[-- Attachment #1: Type: text/plain, Size: 3056 bytes --]

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 <rjhorn@panix.com> wrote:

>
> Ihor Radchenko <yantar92@posteo.net> writes:
>
> > Robert Horn <rjhorn@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
> rjhorn@alum.mit.edu
>

[-- Attachment #2: Type: text/html, Size: 3996 bytes --]