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

[Tim Cross]

Daryl Manning <daryl@wakatara.com> writes:

> 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. 
>

Yes, this is one of the areas where there are some subtle issues to work
through. With regards to just meetings, I see 3 common scenarios

1. Meeting wiht all participants in the same time zone. The time (lets
say 3pm) should not change when daylight savings comes in or goes
out. The meeting is always at 3pm even though that 3pm might be
different when considered against UTC time.

2. A meeting where some participants are in different time zones to the
org user. Here it isn't clear exactly what should happen when there is a
daylight savings transition in the org user's time zone. Should the org
user's meeting time change or should the participants in the other time
zones update their time for the meeting. On one hand, it makes sense
that the local org user change the meeting time for themselves either
forward/back an hour because it is their time zone which has
changed. However, if the meting has a majority of participants in the
same time zone as the org user, perhaps those in the other time zones
should adjust. Point is, it isn't obvious and there isn't a 'right
solution'. Both needs to be supported and probably need to have some way
to indicate which is the preferred behaviour. 

3. An org user who travels and is often in a different time zone from
their 'home' time zone. IN this scenario, they probably want their
meeting times to be adjusted to the local time zone they are in (unless
they are already recorded in that time zone). Note that this was a
specific example form a previous feature request for time zone support
in org time stamps.

This is just wiht respect to timestamps used for meetings. There are
other scenarios with other subtle issues. For example, someone already
mentioned a scenario where org is being used to record details about
experiments. In this situation, the amount of 'real' time passed between
two timestamps is possibly the most important factor. The fact daylight
savings time transitions have occured are likely irrelevant - just
important any calculations relating to duration are accurate and not
thrown out by one hour due to the wall clock moving forward/abck an
hour.

So far, it seems clear that the solution needs to be flexible and
support timestamps without time zone information, with fully qualified
time zone specification, with time zone abbreviated names and with time
zone offsets.

It also seems that the solution will need some mechanism (possibly on a
per time stamp basis) for the user to specify what should happen when
either the time zone has a daylight savings transition, when the
timezone rules change or when the user's 'default' time zone changes
because they have changed locations.