org-table change time from UTC to other timezones

org-table change time from UTC to other timezones

[Alan E. Davis]

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

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?

Thank you,

Alan Davis

-- 
      "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: 2323 bytes --]

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

[Tim Cross]

Alan E. Davis <lngndvs@gmail.com> 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

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

[Alan E. Davis]

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

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 <theophilusx@gmail.com> wrote:

>
> Alan E. Davis <lngndvs@gmail.com> 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)

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

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

[Tim Cross]

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

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

[Alan E. Davis]

[-- 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 --]

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

[Maxim Nikulin]

2020-12-11 Alan E. Davis wrote:
> 
> I had hoped that subtracting 10 hours from 06:44 UTC would get me at 
> least -04:44.

I am in doubts how to present negative time correctly. Having in mind 
wall clocks with hands, your expectation has some sense.

I think, the source of confusion is that you are trying to use 
facilities intended for TimeInterval + TimeInterval arithmetic, where 
TimeInterval denotes a type. Actually you need to compute Time + 
TimeInterval. Sorry, I am unaware if Emacs provides proper functions.

There are a lot of subtle issues with time-related operations, but most 
of DST complications pointed out by Tim could be handled with IANA 
(Olson) DB for time zones, on Linux it is almost always installed as 
tzdata package and is getting regular updates. It is rather precise and 
contains history of DST and other transitions. If people complains on 
incorrect results, usually they have wrong timezone set on their computers.

For astronomy the best representation should be timestamp (seconds since 
epoch) converted to local date time when necessary. Unsure concerning 
leap seconds.

Human-related future events mostly should be stored as date + local time 
+ label of administrative region that allows to get time zone ID (namely 
ID, not offset from UTC). Time offset could be changed after event has 
been planned, time zone could be split into several ones with distinct 
offsets.

- LocalTime + TimeInterval operation could give incorrect result unless 
LocalTime is augmented with date and TimeZone, the latter is the history 
of transitions.
- TimeZone (e.g. Europe/Berlin) as full transition history is not the 
same as TimeOffset at particular moment (+0100).

Carefully choose storage format:
- just Date e.g. for date of birth (adding time or time zone could 
distort results),
- Date + LocalTime + Place for planned events
- Timestamp for most events in past. Use it for future if local time is 
irrelevant, astronomical events is an example.

Conversion to local time could evolve due to administrative decisions.

Examples when Olson DB is not enough and additional negotiations or 
justifications are necessary:

- (March, 31) - (1 month)
- Conversion from Date + LocalTime to Timestamp around time transition 
when non-existing or ambiguous local time is possible.

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

[Alan E. Davis]

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

Maxim:

Thank for the clear explanation.  My little problem seems to require a
super steam hammer.  Your insights are most helpful.

Alan



On Fri, Dec 11, 2020, 07:46 Maxim Nikulin <manikulin@gmail.com> wrote:

> 2020-12-11 Alan E. Davis wrote:
> >
> > I had hoped that subtracting 10 hours from 06:44 UTC would get me at
> > least -04:44.
>
> I am in doubts how to present negative time correctly. Having in mind
> wall clocks with hands, your expectation has some sense.
>
> I think, the source of confusion is that you are trying to use
> facilities intended for TimeInterval + TimeInterval arithmetic, where
> TimeInterval denotes a type. Actually you need to compute Time +
> TimeInterval. Sorry, I am unaware if Emacs provides proper functions.
>
> There are a lot of subtle issues with time-related operations, but most
> of DST complications pointed out by Tim could be handled with IANA
> (Olson) DB for time zones, on Linux it is almost always installed as
> tzdata package and is getting regular updates. It is rather precise and
> contains history of DST and other transitions. If people complains on
> incorrect results, usually they have wrong timezone set on their computers.
>
> For astronomy the best representation should be timestamp (seconds since
> epoch) converted to local date time when necessary. Unsure concerning
> leap seconds.
>
> Human-related future events mostly should be stored as date + local time
> + label of administrative region that allows to get time zone ID (namely
> ID, not offset from UTC). Time offset could be changed after event has
> been planned, time zone could be split into several ones with distinct
> offsets.
>
> - LocalTime + TimeInterval operation could give incorrect result unless
> LocalTime is augmented with date and TimeZone, the latter is the history
> of transitions.
> - TimeZone (e.g. Europe/Berlin) as full transition history is not the
> same as TimeOffset at particular moment (+0100).
>
> Carefully choose storage format:
> - just Date e.g. for date of birth (adding time or time zone could
> distort results),
> - Date + LocalTime + Place for planned events
> - Timestamp for most events in past. Use it for future if local time is
> irrelevant, astronomical events is an example.
>
> Conversion to local time could evolve due to administrative decisions.
>
> Examples when Olson DB is not enough and additional negotiations or
> justifications are necessary:
>
> - (March, 31) - (1 month)
> - Conversion from Date + LocalTime to Timestamp around time transition
> when non-existing or ambiguous local time is possible.
>
>
>

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

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

[Jean Louis]

* Maxim Nikulin <manikulin@gmail.com> [2020-12-11 18:45]:
> 2020-12-11 Alan E. Davis wrote:
> > 
> > I had hoped that subtracting 10 hours from 06:44 UTC would get me at
> > least -04:44.
> 
> I am in doubts how to present negative time correctly. Having in mind wall
> clocks with hands, your expectation has some sense.
> 
> I think, the source of confusion is that you are trying to use facilities
> intended for TimeInterval + TimeInterval arithmetic, where TimeInterval
> denotes a type. Actually you need to compute Time + TimeInterval. Sorry, I
> am unaware if Emacs provides proper functions.
> 
> There are a lot of subtle issues with time-related operations, but most of
> DST complications pointed out by Tim could be handled with IANA (Olson) DB
> for time zones, on Linux it is almost always installed as tzdata package and
> is getting regular updates. It is rather precise and contains history of DST
> and other transitions. If people complains on incorrect results, usually
> they have wrong timezone set on their computers.
> 
> For astronomy the best representation should be timestamp (seconds since
> epoch) converted to local date time when necessary. Unsure concerning leap
> seconds.
> 
> Human-related future events mostly should be stored as date + local time +
> label of administrative region that allows to get time zone ID (namely ID,
> not offset from UTC). Time offset could be changed after event has been
> planned, time zone could be split into several ones with distinct offsets.
> 
> - LocalTime + TimeInterval operation could give incorrect result unless
> LocalTime is augmented with date and TimeZone, the latter is the history of
> transitions.
> - TimeZone (e.g. Europe/Berlin) as full transition history is not the same
> as TimeOffset at particular moment (+0100).

Let me just comment that PostgreSQL database has date/time types such
as:

TIMESTAMP WITHOUT TIME ZONE and
TIMESTAMP WITH TIME ZONE

but all of them are stored without time zone, the difference being
that "WITH TIME ZONE" would only be displayed with specific time
zone.

Same approach can be used in other time storages, just store it as
UTC, display it as you wish.

Jean

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

[Maxim Nikulin]

2020-12-12 Alan E. Davis wrote:
> 
> Thank for the clear explanation.  My little problem seems to require a 
> super steam hammer.  Your insights are most helpful.

You do not need a steam hammer. There are a number of tools around. Some 
of hammers however could not deal with all nails.

Even "date" util could be used to convert between timestamps and human 
readable representation, between timezones. It could even do some arithmetic

date --utc -d @1234567890
Fri Feb 13 23:31:30 UTC 2009

date -d 'now' +%s
1607787784

date -d 'now +10hours' +%s
1607823786

TZ=America/New_York date -d "@`TZ=Europe/Berlin date -d '2020-11-10 
09:08:07 +10hours' '+%s'`"
Mon Nov  9 19:08:07 EST 2020

In my opinion, org mode is too rigid in respect to timestamp format. 
Sometimes I would prefer to specify timestamps with timezone.

Well known example of idiosyncrasy of particular applications. 
Timestamps in xls files are represented by floating point numbers, 
namely days since 1 Jan 1900, fractional part is time. Unfortunately 
1900 is not a leap year, so to avoid unnecessary complications of code 
and keep memory footprint small, on Macs epoch starts in 1904, on 
windows year 1900 has Feb, 29...

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

[Tim Cross]

Maxim Nikulin <manikulin@gmail.com> writes:

> 2020-12-12 Alan E. Davis wrote:
>>
>> Thank for the clear explanation.  My little problem seems to require a
>> super steam hammer.  Your insights are most helpful.
>
> In my opinion, org mode is too rigid in respect to timestamp format.
> Sometimes I would prefer to specify timestamps with timezone.
>
> Well known example of idiosyncrasy of particular applications.
> Timestamps in xls files are represented by floating point numbers,
> namely days since 1 Jan 1900, fractional part is time. Unfortunately
> 1900 is not a leap year, so to avoid unnecessary complications of code
> and keep memory footprint small, on Macs epoch starts in 1904, on
> windows year 1900 has Feb, 29...

Although there are likely some dark corners where bugs can be found, I
think you could probably add timezone data to org timestamps by changing
the default format strings. Org also uses an 'internal' 'time' value to
represent timestamps which are then converted to the required format
using these format strings.

What is possibly missing is an easy way to specify a time zone when
creating a timestamp. I suspect it will default to whatever the local
system tz is and I don't think there is any convenient way to change tz
values like there is for the other timestamp components.

--
Tim Cross

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

[Alan E. Davis]

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

Thank for the ideas.  The 'date' command examples look interesting.

I think R would not be too unwieldy as a hammer here.  My use case  is a
humble one: just take a several clock times in HH:MM format (utc) and
adjust to  another timezone by adding or subtracting the relevant number of
hours.  The day of week is not important; i will have to deal with it.  I
did imagine a conditional subtraction by adding of subtracting 24:00 as
needed.

Much thanks for the advice.

Alan




On Sat, Dec 12, 2020, 15:00 Tim Cross <theophilusx@gmail.com> wrote:

>
> Maxim Nikulin <manikulin@gmail.com> writes:
>
> > 2020-12-12 Alan E. Davis wrote:
> >>
> >> Thank for the clear explanation.  My little problem seems to require a
> >> super steam hammer.  Your insights are most helpful.
> >
> > In my opinion, org mode is too rigid in respect to timestamp format.
> > Sometimes I would prefer to specify timestamps with timezone.
> >
> > Well known example of idiosyncrasy of particular applications.
> > Timestamps in xls files are represented by floating point numbers,
> > namely days since 1 Jan 1900, fractional part is time. Unfortunately
> > 1900 is not a leap year, so to avoid unnecessary complications of code
> > and keep memory footprint small, on Macs epoch starts in 1904, on
> > windows year 1900 has Feb, 29...
>
> Although there are likely some dark corners where bugs can be found, I
> think you could probably add timezone data to org timestamps by changing
> the default format strings. Org also uses an 'internal' 'time' value to
> represent timestamps which are then converted to the required format
> using these format strings.
>
> What is possibly missing is an easy way to specify a time zone when
> creating a timestamp. I suspect it will default to whatever the local
> system tz is and I don't think there is any convenient way to change tz
> values like there is for the other timestamp components.
>
> --
> Tim Cross
>
>

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

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

[Maxim Nikulin]

2020-12-13 Alan E. Davis wrote:
> 
> I think R would not be too unwieldy as a hammer here.  My use case  is a 
> humble one: just take a several clock times in HH:MM format (utc) and 
> adjust to  another timezone by adding or subtracting the relevant number 
> of hours.  The day of week is not important; i will have to deal with 
> it.  I did imagine a conditional subtraction by adding of subtracting 
> 24:00 as needed.

Likely your approach is suitable for you and you could ignore my 
comments. I just live in a city having longitude that should be (and it 
was) the border between time zones, so majority do not like any 
decision. Since cancellation of DST 10 years ago, local time has been 
shifted 2 times...

To get time offset for some timezone, it is necessary to specify 
timestamp, so a date is required in addition to time. Namely day of week 
is mostly irrelevant.

Time transitions are usually arranged at night when most of people are 
not active. Astronomers is a different case, that is why their chance to 
face a timezone bug is higher.

When operations with arbitrary time zones are not required and a process 
could be run with TZ variable set to desired time zone, libc functions 
should work correctly. I have not tried elisp functions 
https://www.gnu.org/software/emacs/manual/html_node/elisp/Time-Zone-Rules.html

A bookmark for those who still hopes to avoid complications with 
time-related operations

Falsehoods programmers believe about time
https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time

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

[Alan E. Davis]

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

Maxim:

Both of these links, like your comments, are incredibly useful.

Happy New Year (however you may measure that thing)

On Sun, Dec 13, 2020 at 9:05 AM Maxim Nikulin <manikulin@gmail.com> wrote:

> 2020-12-13 Alan E. Davis wrote:
> >
> > I think R would not be too unwieldy as a hammer here.  My use case  is a
> > humble one: just take a several clock times in HH:MM format (utc) and
> > adjust to  another timezone by adding or subtracting the relevant number
> > of hours.  The day of week is not important; i will have to deal with
> > it.  I did imagine a conditional subtraction by adding of subtracting
> > 24:00 as needed.
>
> Likely your approach is suitable for you and you could ignore my
> comments. I just live in a city having longitude that should be (and it
> was) the border between time zones, so majority do not like any
> decision. Since cancellation of DST 10 years ago, local time has been
> shifted 2 times...
>
> To get time offset for some timezone, it is necessary to specify
> timestamp, so a date is required in addition to time. Namely day of week
> is mostly irrelevant.
>
> Time transitions are usually arranged at night when most of people are
> not active. Astronomers is a different case, that is why their chance to
> face a timezone bug is higher.
>
> When operations with arbitrary time zones are not required and a process
> could be run with TZ variable set to desired time zone, libc functions
> should work correctly. I have not tried elisp functions
>
> https://www.gnu.org/software/emacs/manual/html_node/elisp/Time-Zone-Rules.html
>
> A bookmark for those who still hopes to avoid complications with
> time-related operations
>
> Falsehoods programmers believe about time
>
> https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time
>
>
>

-- 
      "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: 3347 bytes --]