Re: org-table change time from UTC to other timezones

["Alan E. Davis" <lngndvs@gmail.com>]

[-- 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 --]