Re: org-table change time from UTC to other timezones

["Alan E. Davis" <lngndvs@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4171 bytes --]

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
>


-- 
      "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)

[-- Attachment #2: Type: text/html, Size: 5463 bytes --]