Ihor Radchenko <yanta...@posteo.net> writes: > Tim Cross <theophil...@gmail.com> writes: > >>> Does it sound good enough? >> >> No, I'm afraid not. How does org distinguish between meeting 1 and >> meeting 2? IN meeting one, when the timezone transitions in/out of >> daylight savings, nothing needs to change, but in meeting 2, when this >> occurs, the meeting needs to be re-sechduled so that it keeps the same >> offset relative to UTC. >> Some mechanism is needed so that the user can >> identify timestamps like those fo rmeeting 1 from those for meeting >> 2. My idea was to have meeting 1 type timestamps without TZ info and >> meeting 2 require fully qualified TZ info. However, while this would >> probably work, I don't like it because it isn't explicit and would be >> prone to errors. > > I still don't understand. > > In Org, you will have a default time zone that will be used to build the > agenda. > > In meeting 1, you set the time zone to your local zone > In meeting 2, you set the time zone to the time zone where the meeting > is scheduled. > > The, both the meetings will be first converted to the default time zone > and appear in your agenda adjusted as required.
The problem is with meeting 2 and the assumption there is a definitive timezone for the meeting. Consider this scenario. I have a meeting with two other people. We are all in different timezone. What is the timezone of the meeting? Thinking more about it, in this situation, you probably just need to set the meeting time to UTC and that would work. However, we would want some easy way to set this when creating the timestamp (and that could be all that is needed - a good enhancement to the interface to make it easy to set the timezone) and good control over how values are displayed in the agenda and org files (i.e. I imagine you might want a default where they are all shown in your local time, but similar to working with links, the ability to display the 'raw' version for editing and other purposes). As yuou mentioned in another thread, it is likely many of these scenarios can be adequately managed with good TZ support. It will be critical that we also have a good UI for setting/adding TZ information. Then, as you pointed out elsewhere, we will just need good documentation/tutorials as some of these workflows are not terribly intuitive and people find this stuff confusing.
