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: Tue, 17 Jan 2023 20:45:04 +1100
User-agent: mu4e 1.9.14; emacs 29.0.60

Ihor Radchenko <yantar92@posteo.net> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>
>> 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. 
>
> 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.

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.

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.

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.

So, for the first 2 I probably need to somehow flag/indicate that I do
or do not want the time adjusted as a result of a daylight savings
transition. For the 3rd group, I only want adjustments for timestamps
which are not in the 'current' (where I've travelled to) time zone. The
final one is really just about ensuring the transitions don't throw out
duration calculations accidentally.



reply via email to

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