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: Robert Horn
Subject: Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
Date: Thu, 19 Jan 2023 11:56:26 -0500
User-agent: mu4e 1.8.1; emacs 28.1

Ihor Radchenko <yantar92@posteo.net> writes:

> Robert Horn <rjhorn@panix.com> writes:
>
>>> Not really. Countries may change DST at any moment in future. Or decide
>>> to switch calendars (consider countries near the day transition line).
>>>
>>> And "past local time, according to the DST rules in effect at the time"
>>> is also an option that might be useful in certain scenarios.
>>>
>> The issue is clarity of the expected rules for the format.  If I
>> schedule a meeting for 10:05 DST, but the rules change so that it is not
>> DST at that location at that time in the future, what is the expected
>> interpretation?  It could be:
>
> Let me clarify. I do not think that we need to offer selecting DST/no
> DST in the timestamp. Instead, we offer something like
> <2028-12-11 18:00@Europe/Berlin>, specifying local time, including
> possible DST transitions or any other political decisions the country
> might make regarding the local time rules.
>

That would cover it for me.  So, 18:00@Europe/Berlin is the "then local
time", 18:00@CET would be Central European standard time and 18:00@CEST
would be Central European Summer Time.  18:00@UTC would be 19:00@CET and
18:00@CEST. I've found that by far the most common scheduling uses the
"then local time" because that's what people usually want.  I know when
someone schedules a meeting in late March they rarely figure out whether
it will be summer time or standard time.


> Or, if the preference is specifying time in such a way that it is
> unaffected by the local time rules (for example, "+10000 hours from now,
> no matter what the DST/no DST or whatever rules will happen in the
> middle"), one can use explicit UTC offsets like <2028-12-11
> 18:00@UTC+02>

Interesting question.  Some uses (like scheduling physical process) want
+4 hours to mean 4 hours later regardless of leap seconds or summer time
changes.  But most people scheduling issues where they say "in 24 hours"
they actually mean +24 in local time.  At the transition to or from
summer time the phrase "within 24 hours" usually means 24 hours except
on the transition days when it's 23 or 25 hours.

Don't worry about TAI.  People who are working in TAI are unlikely to
expect org to support TAI. 


-- 
Robert Horn
rjhorniii@gmail.com



reply via email to

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