I am close to throwing in the towel.=C2=A0
=

Thank you for the suggestion.=C2=A0 Several problems ha= ve been encountered.=C2=A0 I wonder whether I understand this tool at all.= =C2=A0=C2=A0 If I subtract 10:00 from 08:46, the answer given is -01:14.=C2= =A0 I used #+TBLFM: \$6=3D\$4+\$5;U, as follows (please forgive the formatting= ):

| Phenom | =C2=A0 Date | DoW | =C2=A0 UTC | = =C2=A0 =C2=A0Hrs | =C2=A0 ChST | =C2=A0 |
|--------+--------+-----+--= -----+--------+--------+---|
| ApoG =C2=A0 | =C2=A0 =C2=A0 22 | Fr = =C2=A0| 06:44 | -10:00 | -03:16 | =C2=A0 |
|--------+--------+= -----+-------+--------+--------+---|
=C2=A0 =C2=A0 =C2=A0 #+TBLFM: \$6=3D= \$4+\$5;U

When I add 10:00, I think the values a= re sensible: 21:45 + 10:00 =3D 31:45.=C2=A0

A= nother problem was in trying to use an inactive org timestamp.=C2=A0 It was= not straightforward to add or subtract N hours (say, 08:00).=C2=A0=C2=A0 <= br>

This it a thornier problem than I had envision= ed, anyway, because in locale with time zones, the conversion factor will c= hange at some point DURING the month.=C2=A0

P= erhaps 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/f= rom Daylight Time.=C2=A0

For now,
<= /div>
O= n Wed, Dec 9, 2020 at 3:40 AM Tim Cross <theophilusx@gmail.com> wrote:

Alan E. Davis <ln= gndvs@gmail.com> writes:

> I have been pleased to learn that I can add / subtract hours in org-ta= ble
> to shift time zones.=C2=A0 I am making tables of=C2=A0 lunar/solar par= ameters
> relevant to tides.=C2=A0 Org-table is a convenient way to enter data i= n a
> tabular format that can be printed via LaTeX.=C2=A0 So each year, for = several
> time zones, I enter these times by hand.
>
> It's very, very easy, I have learned, to collect all of these time= s (at
> most, maybe 12 per month) for UTC, and add or subtract to generate a c= olumn
> of times for a new time zone.=C2=A0 Very Slick!
>
> Except that when I add, for example. 09:00 to 23:33, I guess it is pre= tty
> obvious what is going to happen: it would be the same day, but at 32:3= 3 !!
>
> I have tripped up on trying to test for whether the sum is greater tha= n or
> equal to 24:00, and then doing something interesting with it.=C2=A0 It= 's
> actually pretty easy to go through all the months and find the excepti= ons,
> and make manual changes.=C2=A0 But, as I usually have done, I would ra= ther spend
> a few hours coming up with some programmatic method for making this wo= rk
> automatically!
>
> The other problem is the change of the day.=C2=A0 I suppose I could us= e 0, 1,
> 2... for Sunday, Monday, Tuesday...=C2=A0 (I am living in the United S= tates).
>
> Has someone solved this problem?
>

Org tables support formulas which use the Emacs 'calc' program. Cal= c has
pretty good support for adding, subtracting, multiplying and otherwise
manipulating dates and times (this is how the org clocktable works). It
should be pretty straight forward to have a column of date + time
values, a time offset representing a timezone and a 3rd column which is
the new date/time after applying the offset. Have a look at the secton
in the org manual on table formulas and the calc manual in info.

--
Tim Cross

--
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &qu= ot;This ignorance about the limits of the earth's ability to absorb
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pollutants should be reason enough for= caution in the release
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 of pollutin= g substances."
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0=C2=A0 ---Meadows et al.=C2=A0=C2=A0= 1972.=C2=A0 Limits to Growth. =C2=A0=C2=A0 =C2=A0 (p. 81)=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=
--000000000000b8b10905b617b8fb--