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

[Max Nikulin]

On 21/01/2023 16:21, Ihor Radchenko wrote:
> I looked into this further and I note that
> `calendar-absolute-from-gregorian' does not account for time zones at
> all:
>
>            ((> year 0)
>             (setq offset-years (1- year))
>             (+ (calendar-day-number date) ; days this year
>                (* 365 offset-years)       ; + days in prior years
>                (/ offset-years 4)         ; + Julian leap years
>                (- (/ offset-years 100))   ; - century years
>                (/ offset-years 400)))     ; + Gregorian leap years
>
> Diary sexps are using this function frequently.
> In fact, Org also does use this function frequently.

I have not look into this package yet, so I can not comment it.

Should we summon Paul Eggert?
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54764#10
Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list
 argument optional ones Sat, 9 Apr 2022 00:52:57 -0700
> Generally speaking, 
> when Org mode is doing calendrical calculations it should use 
> calendrical functions rather than encode-time+decode-time, which are 
> best used for time calculations not calendar calculations.

On 21/01/2023 16:21, Ihor Radchenko wrote:
> Probably, the only sane way to address all the pitfalls with time zones
> while using calendar functions is first converting the date to UTC
> before passing it to diary sexps and calendar functions. I hope that UTC
> is at least not affected by all the crazy time transitions various time
> zones have.

It may be tricky to get start of day / end of day or advance timestamp 
by given number of days having timestamp as seconds since epoch. If you 
mean broken-down time representation in UTC then I am unsure which way 
you are going to handle skipped 2011-12-30 case, since dates in UTC are 
rather regular.

> but I am afraid
> that rewriting agenda to support UTC is going to transform into
> rewriting agenda completely + rewriting Emacs diary.

I still suspect that to implement timezone support in Org it will be 
necessary to create a custom library to handle zoneinfo files.