From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id ABUXBi39019wVQAA0tVLHw (envelope-from ) for ; Fri, 11 Dec 2020 23:13:49 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id tBjdAS39019ERwAA1q6Kng (envelope-from ) for ; Fri, 11 Dec 2020 23:13:49 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id B15C5940429 for ; Fri, 11 Dec 2020 23:13:48 +0000 (UTC) Received: from localhost ([::1]:33184 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1knrbe-0000X3-H7 for larch@yhetil.org; Fri, 11 Dec 2020 18:13:47 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:40894) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1knr9P-00056e-GG for emacs-orgmode@gnu.org; Fri, 11 Dec 2020 17:44:35 -0500 Received: from mail-wm1-x333.google.com ([2a00:1450:4864:20::333]:36346) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1knr9A-0001E6-5n for emacs-orgmode@gnu.org; Fri, 11 Dec 2020 17:44:35 -0500 Received: by mail-wm1-x333.google.com with SMTP id y23so10011834wmi.1 for ; Fri, 11 Dec 2020 14:44:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QZ+ekIhRvOO5V5J7XRE29elnn6sc8Ln+RZkl4yA4H44=; b=TObwT+FvT852kxv8Oupt6FKmC8N6dU0QR4t3VxPhOtTdZhyOIG5UhR1sSARzJQbeMR 5ktpM6LUUpMqZJ5jZwOxxQ2BrqSSZb65bXedIYX6T6W+y47n/4eT6ijRZccQe/JHJkoz H+VpJr7XVQKgdITGKUmmDfa6gQYuwHuetziQ9Vic3qtv3fgJk8KlnoJt1hJSXIo35anf zopkePZ5ZsliX6qaeWBhHd7v2vgwjWThuFqYkThlNwIWHe4BFqxEoLsarNs/oWyCebdo ZHkat2bYwnko4Yo0IfZbdYdHVk/WiErxY8tLXwBcabcKVjF4hZaRxQFT4eNsRknmJQ5y 0gww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QZ+ekIhRvOO5V5J7XRE29elnn6sc8Ln+RZkl4yA4H44=; b=ZBy2w1t3rcPPTa2T11cWepK4+20O36ydG+ntqh5uNQDaaiBV0z6iTsprYQYUBpfCe8 wvtIUx9OtJK+qQXs77nLYUuK61sNgN3O367O7ov5s2tnXE+5ZiRC936kTzhvy0emdTHf 4KYEDSyeFAwjp+Q/jXM8Rh868rlFmj12haJI7WPhhvJ+ZE4uRfwPBEw/Z3PGpTxxVzTq s1ISM0CkmedYfUGTtF7lEhDe6ZKoEGmqZ2ZvK1qrNHzfNlTUsOZ3MewGQcDO9bQzIfF2 Eo5aLQZyh7wEL0E9fyhG0PDMXjNo/m1FAim3cZejj5m3Xuxgh+NOBH6WrARWGh9EbD3M ZV8Q== X-Gm-Message-State: AOAM530v9Q3yPOSqdHAU3krzhVlZHwjdi1BlJymecc8cSWdxsFbYa3g/ QQDLiTE1lLhSeRjpo0m1mtRO2QGDfdHeVaVpnjM= X-Google-Smtp-Source: ABdhPJzxhB/8qxcbI7Ng04uu7sX5a9leDxCRH/xs4VMFgo8TGsBKvpeLxaaxU2vVF3fB2K+nOq/boGiegQr1ycmu9YQ= X-Received: by 2002:a1c:2b46:: with SMTP id r67mr15702045wmr.162.1607726658209; Fri, 11 Dec 2020 14:44:18 -0800 (PST) MIME-Version: 1.0 References: <87wnxrjjl2.fsf@gmail.com> <87lfe5ju0t.fsf@gmail.com> In-Reply-To: From: "Alan E. Davis" Date: Fri, 11 Dec 2020 14:44:07 -0800 Message-ID: Subject: Re: org-table change time from UTC to other timezones To: Maxim Nikulin Content-Type: multipart/alternative; boundary="0000000000005bcc7805b6380820" Received-SPF: pass client-ip=2a00:1450:4864:20::333; envelope-from=lngndvs@gmail.com; helo=mail-wm1-x333.google.com X-Spam_score_int: -8 X-Spam_score: -0.9 X-Spam_bar: / X-Spam_report: (-0.9 / 5.0 requ) BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.344, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: org-mode Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -3.00 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=TObwT+Fv; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Queue-Id: B15C5940429 X-Spam-Score: -3.00 X-Migadu-Scanner: scn1.migadu.com X-TUID: AhRAZULegqk+ --0000000000005bcc7805b6380820 Content-Type: text/plain; charset="UTF-8" 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 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. > > > --0000000000005bcc7805b6380820 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Maxim:

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

Alan
=


=
On Fri, Dec 11, 2020, 07:46 Maxim Nik= ulin <manikulin@gmail.com>= wrote:
2020-12-11 Alan E. Davis wr= ote:
>
> I had hoped that subtracting 10 hours from 06:44 UTC would get me at <= br> > 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.


--0000000000005bcc7805b6380820--