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

[Tim Cross <theophilusx@gmail.com>]

Ihor Radchenko <yantar92@posteo.net> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>
>> Daryl mentioned elsewhere in this thread that how hard this feature
>> would be depends largely on the available libraries for elisp with
>> respect to working with date/time values. Sadly, the available elisp
>> libraries are inadequate in this area. While many of the functions can
>> be called with an optional argument defining time zone information,
>> there is no library which can retrieve this information in a consistent
>> manner and which supports historical data lookup e.g. what were the DST
>> transition dates for NSW Australia in 1970 (trick questions, NSW didn't
>> adopt DST until 1971). The existing library functions are focused more
>> on simpler time calculations where time zone information is less
>> relevant i.e. running timers, timing command execution, comparing file
>> modification times etc. Sometimes, it is easy to forget that while Elisp
>> is powerful, it isn't really a general purpose programming language like
>> C or Rust or even CL and Scheme. It is primarily a programming language
>> focused  on a specific domain, the editor. While it has some great
>> libraries  it also has  anumber of areas where it lacks the sort of
>> sophistication we have grown to expect with more general purpose
>> languages.
>
> Emacs' own time zone support is relying on external libraries. AFAIU,
> historical context should be handled no worse than in the OS.
>
> More precisely, tzlookup from timefns.c relies on time.h and Windows
> equivalents. All the heavy lifting is done by core OS libraries.
>
>> A further complication is that accessing date and time related data is
>> very system dependent and there is no high level library which abstracts
>> this so that you  can easily get consistent results across all the
>> platforms Emacs runs on. Even the underlying data type can vary greatly
>> (i.e. some platforms use a 64 bit value while others only use a 32 bit one).
>
> This is not the problem we need to worry about. We can use whatever
> Emacs provides and rely on future improvements in Emacs where things are
> deficient. We should not aim for 100% accurate time zone support. Just
> good enough. It's not Org's job to implement the gory details of time
> zone support.

I guess we will have to disagree here. If org is going to claim to
support time zones, then 100% accurate is IMO essential. As it stands
now, we don't claim TZ support and time calculations are correct on the
basis they are all done relative to current locale. However, once you
add TZ information, if you don't apply it consistently and correctly,
that means the values can no longer be relied upon.

Or to put it in another way - currently, it is well understood where org
timestamps fall down. However, once you add TZ and provide the
expectation TZ data will be respected correctly, all bets are off.

Anyway, I've made my point and will leave it alone now. Ironically, time
will tell us who is right and who isn't.