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 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 . (p. 81)