Ihor Radchenko <yanta...@posteo.net> writes: > Tim Cross <theophil...@gmail.com> writes: > >>> Could you please elaborate here? >> >> I have some meetings scheduled in my org files which show up in the >> agenda. >> >> Meeting 1 is a reoccurring meeting which happens every 2 weeks. All of >> the people in that meting are in the same timezone as I'm in. When we >> transition into/out of daylight savings time, I don't want the timestamp >> to change. THe meeting will remain at 3pm. > > Specifying the timezone should be good enough. > Not specifying will put you at a risk if you travel (you default OS > timezone will likely change). > >> Meeting 2. This is also a reoccuring meeting. However, this meeting is >> with people from a number of idfferent time zones. When my timezone >> moves into or out of daylight savings time, I need the meeting time to >> be updated - moved forward/back 1 hour. > > Again, you can just specify the right timezone and let Org translate it > to local one when calculating agenda. > >> Next week, I'm travelling to a different city for work and will be in a >> different timezone. I need all my meetings to be adjusted except for >> those I've already booked that are in the timezone I willl be in while >> I'm away. > > If you don't specify the timezone for both old and new meetings, there > will be no easy way to deal with this. What you may have to do is: (1) > indicate explicit timezone for the meetings in the new place (there will > probably be less of them compared to all other meetings); (2) tell Org > to use your old time zone as default - it will make the previously > scheduled meetings without timezone info use the right time zone. > >> Finally, I have a few timestamps I use to track some projects and >> progress on various tasks as well as reports showing actual and >> estimated effort comparisons as well as managing billing/invoicing. The >> actual timestamp times are less important than the calculation of >> durations etc. When durations do cross daylight savings transition >> points, it is critical that additonal hours are not accidentally >> added/removed from the duration calculation. Mistakes here could result >> in me loosing revenue or over charging clients. > > For the past timestamps, you can either: (1) make Org put UTC offsets > when recording clock data; (2) use the idea we discussed about multiple > default time zones where you can specify different time zones at > different periods of time (before after travel). > > 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. Note that the above is a real scenario - I have to deal with this type of problem frequently. The other types can, in general, be handled through judicious use of TZ settings.
