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.
