emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: "Alan E. Davis" <lngndvs@gmail.com>
To: Maxim Nikulin <manikulin@gmail.com>
Cc: org-mode <emacs-orgmode@gnu.org>
Subject: Re: org-table change time from UTC to other timezones
Date: Fri, 11 Dec 2020 14:44:07 -0800	[thread overview]
Message-ID: <CAF-1L2QrWwPaZygp2_Pxo+Hye1keYfAX76qLmvQta9BoFa514w@mail.gmail.com> (raw)
In-Reply-To: <rr03t2$3j7$1@ciao.gmane.io>

[-- Attachment #1: Type: text/plain, Size: 2601 bytes --]


Thank for the clear explanation.  My little problem seems to require a
super steam hammer.  Your insights are most helpful.


On Fri, Dec 11, 2020, 07:46 Maxim Nikulin <manikulin@gmail.com> wrote:

> 2020-12-11 Alan E. Davis wrote:
> >
> > I had hoped that subtracting 10 hours from 06:44 UTC would get me at
> > least -04:44.
> I am in doubts how to present negative time correctly. Having in mind
> wall clocks with hands, your expectation has some sense.
> I think, the source of confusion is that you are trying to use
> facilities intended for TimeInterval + TimeInterval arithmetic, where
> TimeInterval denotes a type. Actually you need to compute Time +
> TimeInterval. Sorry, I am unaware if Emacs provides proper functions.
> There are a lot of subtle issues with time-related operations, but most
> of DST complications pointed out by Tim could be handled with IANA
> (Olson) DB for time zones, on Linux it is almost always installed as
> tzdata package and is getting regular updates. It is rather precise and
> contains history of DST and other transitions. If people complains on
> incorrect results, usually they have wrong timezone set on their computers.
> For astronomy the best representation should be timestamp (seconds since
> epoch) converted to local date time when necessary. Unsure concerning
> leap seconds.
> Human-related future events mostly should be stored as date + local time
> + label of administrative region that allows to get time zone ID (namely
> ID, not offset from UTC). Time offset could be changed after event has
> been planned, time zone could be split into several ones with distinct
> offsets.
> - LocalTime + TimeInterval operation could give incorrect result unless
> LocalTime is augmented with date and TimeZone, the latter is the history
> of transitions.
> - TimeZone (e.g. Europe/Berlin) as full transition history is not the
> same as TimeOffset at particular moment (+0100).
> Carefully choose storage format:
> - just Date e.g. for date of birth (adding time or time zone could
> distort results),
> - Date + LocalTime + Place for planned events
> - Timestamp for most events in past. Use it for future if local time is
> irrelevant, astronomical events is an example.
> Conversion to local time could evolve due to administrative decisions.
> Examples when Olson DB is not enough and additional negotiations or
> justifications are necessary:
> - (March, 31) - (1 month)
> - Conversion from Date + LocalTime to Timestamp around time transition
> when non-existing or ambiguous local time is possible.

[-- Attachment #2: Type: text/html, Size: 3213 bytes --]

  reply	other threads:[~2020-12-11 23:13 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-09 10:20 org-table change time from UTC to other timezones Alan E. Davis
2020-12-09 11:34 ` Tim Cross
2020-12-10  8:10   ` Alan E. Davis
2020-12-10 19:01     ` Tim Cross
2020-12-11  0:12       ` Alan E. Davis
2020-12-11 15:40         ` Maxim Nikulin
2020-12-11 22:44           ` Alan E. Davis [this message]
2020-12-12 16:04             ` Maxim Nikulin
2020-12-12 22:52               ` Tim Cross
2020-12-13  3:14                 ` Alan E. Davis
2020-12-13 17:03                   ` Maxim Nikulin
2020-12-14  2:29                     ` Alan E. Davis
2020-12-12  3:31           ` Jean Louis

Reply instructions:

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 \
    --in-reply-to=CAF-1L2QrWwPaZygp2_Pxo+Hye1keYfAX76qLmvQta9BoFa514w@mail.gmail.com \
    --to=lngndvs@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=manikulin@gmail.com \


* 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).