emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Tim Cross
Subject: Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
Date: Wed, 18 Jan 2023 22:43:56 +1100
User-agent: mu4e 1.9.16; emacs 29.0.60

Ihor Radchenko <yantar92@posteo.net> writes:

> Tim Cross <theophilusx@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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]