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.
Another problem was in trying to use an inactive org timestamp. It was not
straightforward to add or subtract N hours (say, 08:00).
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,
On Wed, Dec 9, 2020 at 3:40 AM Tim Cross <[email protected]> wrote:
>
> Alan E. Davis <[email protected]> writes:
>
> > I have been pleased to learn that I can add / subtract hours in org-table
> > to shift time zones. I am making tables of lunar/solar parameters
> > relevant to tides. Org-table is a convenient way to enter data in a
> > tabular format that can be printed via LaTeX. 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 times (at
> > most, maybe 12 per month) for UTC, and add or subtract to generate a
> column
> > of times for a new time zone. Very Slick!
> >
> > Except that when I add, for example. 09:00 to 23:33, I guess it is pretty
> > obvious what is going to happen: it would be the same day, but at 32:33
> !!
> >
> > I have tripped up on trying to test for whether the sum is greater than
> or
> > equal to 24:00, and then doing something interesting with it. It's
> > actually pretty easy to go through all the months and find the
> exceptions,
> > and make manual changes. But, as I usually have done, I would rather
> spend
> > a few hours coming up with some programmatic method for making this work
> > automatically!
> >
> > The other problem is the change of the day. I suppose I could use 0, 1,
> > 2... for Sunday, Monday, Tuesday... (I am living in the United States).
> >
> > Has someone solved this problem?
> >
>
> Org tables support formulas which use the Emacs 'calc' program. Calc 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
>
>
--
"This ignorance about the limits of the earth's ability to absorb
pollutants should be reason enough for caution in the release
of polluting substances."
---Meadows et al. 1972. Limits to Growth
<https://www.dartmouth.edu/~library/digital/publishing/meadows/ltg/>.
(p. 81)
