[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Idea for handling timezones
From: |
Maxim Nikulin |
Subject: |
Re: Idea for handling timezones |
Date: |
Sun, 4 Apr 2021 23:06:41 +0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 |
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.
- Re: Idea for handling timezones, (continued)
- Re: Idea for handling timezones, tomas, 2021/04/03
- Re: Idea for handling timezones, shironeko, 2021/04/03
- Re: Idea for handling timezones, tomas, 2021/04/03
- Re: Idea for handling timezones, Shironeko, 2021/04/03
- Re: Idea for handling timezones, Greg Minshall, 2021/04/03
- Re: Idea for handling timezones, Russell Adams, 2021/04/03
- Re: Idea for handling timezones, Greg Minshall, 2021/04/03
- Re: Idea for handling timezones, Samuel Wales, 2021/04/03
- Re: Idea for handling timezones, Tim Cross, 2021/04/03
- Re: Idea for handling timezones, Tom Gillespie, 2021/04/03
- Re: Idea for handling timezones,
Maxim Nikulin <=
- Re: Idea for handling timezones, Shironeko, 2021/04/22
- Re: Idea for handling timezones, tomas, 2021/04/23
- Re: Idea for handling timezones, tomas, 2021/04/03
- Re: Idea for handling timezones, Shironeko, 2021/04/03
- Re: Idea for handling timezones, Shironeko, 2021/04/03
Re: Idea for handling timezones, Tim Cross, 2021/04/02
Idea for handling timezones, Shironeko, 2021/04/02