From: Maxim Nikulin <firstname.lastname@example.org>
Subject: Re: Idea for handling timezones
Date: Sun, 4 Apr 2021 23:06:41 +0700 [thread overview]
Message-ID: <email@example.com> (raw)
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:
timezone Tag Info
Falsehoods programmers believe about time
Emacs API is hardly suitable for working with multiple time zones.
Something could be borrowed from other projects, e.g.
Low-Level Date Algorithms (C++)
A special attribute has been added in python to deal with local time
ambiguity around time transitions
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.
next prev parent reply other threads:[~2021-04-04 16:07 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-01 7:40 shironeko
2021-04-02 11:34 ` tomas
2021-04-03 0:36 ` Shironeko
2021-04-03 7:56 ` tomas
2021-04-03 8:03 ` shironeko
2021-04-03 8:30 ` tomas
2021-04-03 9:26 ` Shironeko
2021-04-03 11:23 ` Greg Minshall
2021-04-03 15:00 ` Russell Adams
2021-04-03 18:51 ` Greg Minshall
2021-04-03 20:06 ` Samuel Wales
2021-04-03 22:47 ` Tim Cross
2021-04-04 0:51 ` Tom Gillespie
2021-04-04 16:06 ` Maxim Nikulin [this message]
2021-04-23 1:45 ` Shironeko
2021-04-23 7:54 ` tomas
2021-04-03 12:43 ` tomas
2021-04-03 12:47 ` Shironeko
2021-04-03 13:20 ` Shironeko
2021-04-02 23:37 ` Tim Cross
2021-04-03 0:31 ` Samuel Wales
2021-04-03 0:43 ` Shironeko
2021-04-03 0:53 ` Samuel Wales
-- strict thread matches above, loose matches on Subject: below --
2021-03-31 2:23 Shironeko
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).