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 <theophil...@gmail.com> wrote:
>
> Alan E. Davis <lngn...@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
>
--
"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)
