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 wrote: > > Alan E. Davis 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 > -- "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 . (p. 81)