Org-mode mailing list
 help / color / mirror / 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
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 --]

Maxim:

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

Alan



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 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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://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 \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Org-mode mailing list

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://orgmode.org/list/0 list/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 list list/ https://orgmode.org/list \
		emacs-orgmode@gnu.org
	public-inbox-index list

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.emacs.orgmode
	nntp://news.gmane.io/gmane.emacs.orgmode


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git