Re: Idea for handling timezones

[Maxim Nikulin <manikulin@gmail.com>]

The notes below are quite general and unrelated to particular message.

On 04/04/2021 07:51, Tom Gillespie wrote:
> 
> followed by a space and then the repeat or delay for example
> [+10000-01-01 10:11:00,992315771-04:00 Sat] or
> [-480-08-20 05:00+01:00]
> or more temporally local
> [2021-03-03 17:43-07:00 Sat]

Just an idea, I do not know if it is feasible and convenient. Have 
anyone considered a kind of src blocks to describe timestamps? Current 
inline syntax is suitable for simple cases, sometimes more details are 
required, some information could be redundant to allow consistency check:

- Date-time in the original form as it appeared in external source (with 
a hint related to particular format e.g. rfc822 date.
- Either it is local time or it is bound to some event as Solar eclipse.
- List if time zones to have notion of local time of all participants of 
an online meeting.
- Location for planned event since there is a chance that existing time 
zone will be split into smaller ones.

A couple of bookmarks to get impression of complexity:
- https://stackoverflow.com/tags/timezone/info
   timezone Tag Info
- 
https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time
   Falsehoods programmers believe about time
   and follow-ups.

Emacs API is hardly suitable for working with multiple time zones. 
Something could be borrowed from other projects, e.g.
https://howardhinnant.github.io/date_algorithms.html
Low-Level Date Algorithms (C++)
A special attribute has been added in python to deal with local time 
ambiguity around time transitions
https://docs.python.org/3/library/datetime.html#datetime.datetime.fold
https://www.python.org/dev/peps/pep-0495/
PEP 495 -- Local Time Disambiguation

I think, it is a challenge to provide a convenient way to generate 
agenda for a trip across several time zones.

P.S. Raw UNIX timestamp as 1234567890 is convenient for some 
computations but hardly human friendly. UTC date-time 
2009-02-13T23:31:30Z is better. With particular offset 
2009-02-13T22:31:30-01:00 it is equally precise and even more 
convenient. Still neither of such forms are applicable if it is 
scheduled event with fixed local time and offset of particular timezone 
might be changed.