Thank you for taking the time to answer my questions, TIm.

For my purposes, it's maybe easier to just bite the bullet and do it in my head.

I had hoped that subtracting 10 hours from 06:44 UTC would get me at least -04:44. I can easily make the change to correct clock time (19:44) and change the day name. I was duplicating the work of looking up the time in XEphem, the ephemeris program I am using, which requires some amount of fiddling---solving for the time of max/min lunar declination. It will save hours of time to use org-mode's spreadsheet to add/subtract the Timezone offsets.

As it turns out, this is not a straightforward procedure. Also, as you point out, this process is even less convenient due to inconsistencies in the political realm.

I appreciate your comments.

Alan Davis

On Thu, Dec 10, 2020 at 12:17 PM Tim Cross <theophilusx@gmail.com> wrote:

Alan E. Davis <lngndvs@gmail.com> writes:

> I am close to throwing in the towel.
>
> Thank you for the suggestion. Several problems have been encountered. I
> wonder whether I understand this tool at all. If I subtract 10:00 from
> 08:46, the answer given is -01:14. I used #+TBLFM: $6=$4+$5;U, as follows
> (please forgive the formatting):
>
> | Phenom | Date | DoW | UTC | Hrs | ChST | |
> |--------+--------+-----+-------+--------+--------+---|
> | ApoG | 22 | Fr | 06:44 | -10:00 | -03:16 | |
> |--------+--------+-----+-------+--------+--------+---|
> #+TBLFM: $6=$4+$5;U
>
> When I add 10:00, I think the values are sensible: 21:45 + 10:00 = 31:45.
>

What did you expect for 8:46 - 10:00? Looks correct to me or were you
expecting 22:46 (24:00 - 01:14)? This would mean 21:45 + 10:00 should be
07:45. I think when your working with times like this, you need to
include the date to help make sense of the result.

> Another problem was in trying to use an inactive org timestamp. It was not
> straightforward to add or subtract N hours (say, 08:00).
>

You probably need to use the ort-timestamp-to-time and
org-timestmap-from-time to convert the timestamp to a 'time' value (I
suspect it uses either ms or sec since epoch as the base). Convert to
time, add/subtract offset, convert back to inactive timestamp.

> This it a thornier problem than I had envisioned, anyway, because in locale
> with time zones, the conversion factor will change at some point DURING the
> month.
>
> Perhaps there is a calc procedure to convert time zones that will take into
> account the system's knowledge of the timezones as well as changes to/from
> Daylight Time.
>
> For now,
>

The big pain with working on time and timezones is the daylight savings
complication. This is really tricky because the start and end date tend
to be influenced by politics (I've seen DST change because of some
event, like Olympic games or to coincide with easter holiday etc) and
some states/geographies may decide not to use DST while others do (for
example, in Australia, some states have DST and some don't - so for half
the year, all the eastern states have the same timezone, but then for
half the year, 3 are the same and one is different).

There is some information in the calendar section of the emacs manual
which might be useful and it does have a section on working with DST
(I've not read it). In addition to the org mode functions to manipulate
dates and times, there are also various elisp functions you can also
use.

It is a thorny problem because of the edge cases, but the basic
functions are all there. Your best bet is to probably write a function
which accepts a full date+time and UTC offset in minutes which returns a
new date+time value and then call that function in your table formula.
--
Tim Cross