[sf-lug] Timezone trouble (was: Virtual meeting of Sunday February 7, 2021)

[Rick Moen]

Quoting Bobbie Sellers (bliss-sf4ever at dslextreme.com):

> Rick gave a talk about using "world clock" to determine the time for
> other virtual meetings.  Unforturnately it seems my copy failed.
> Perhaps he will write it up for the list.

One aspect of our current situation:  Suddenly, out of necessity, the
world is making huge use of virtual meeting software (Zoom, Jitsi Meet,
Big Blue Button, Microsoft Teams, all that stuff), including LUGs -- 
and one silver lining is that anyone with Internet access can now attend
_many_ LUG meeting without leaving home.  And, mostly thanks to Michael
Paoli, there's an excellent list of known online LUG meetings:

https://www.wiki.balug.org/wiki/doku.php?id=balug:covid-19

But there's a procedural hurdle:  Let's say you follow links and
discover the next Birmingham LUG (West Midlands, UK) meeting will 
be online at 19:30 local time, Tuesday, Feb. 16, 2021.  Great!  You go
to add that to your calendar, and... um....

What _time_ will that be, Pacific Time, when Tuesday the 16th rolls
around?


It'd be nice if the Birmingham LUG people had a lovely little pulldown
widget on their Web page for us dodgy foreigners to pick our timezone
and it automagically shows the _user's_ time for the event.  No such
luck.  They're still reflecting the old before-times assumption that
only people in the West Midlands or at most elsewhere in the UK or
Ireland would _ever_ want to know when a Birmingham LUG event will be.


So, we're back to:  What's a low-hassle way to convert arbitary
future-event date/times elsewhere in the world to the date/time _here_
so you can attend?

I know the way most people think, and frankly find it a bit depressing:
"I know!  Let's outsource the problem to whatever's the first Web site
with a timezone converter widget we find by Web searching.  Tons of
those exist, like https://www.timeanddate.com/worldclock/converter.html .
If you're happy with outsourcing to some stranger's proprietary code,
great!  You're done.  Be happy.

Some of us, though, are Linux users and don't outsource computing to
strangers if we can reasonably do it ourselves using our own computing
resources, preferably using open source tools we understand and are under
_our_ control.  So, a long while back, I thought 'Fsck outsourcing.
This can't be hard to do using standard Unix tools.'  I poked around a
bit, hit a wall at that time, and parked the problem for a while -- but
meanwhile found an elegant solution to a different but related problem:

Suppose you wanted to know what time it is, _now_ at a list of
interesting places around the world?

Again, there's the same tiresome standard answer:  Find some stranger's
Web site where you can enter six or seven city names, and have the site
show current time for all of them.  Gobs of such pages exist.  Often,
there's a limit of, say, four cities unless you pay them subscription
money.

Fsck all of that.  It turns out that there's an elegant solution.

The /usr/share/zoneinfo/ tree includes a large subtree of entries
describing timezones around the world.  Long story about that, omitted
here.  But you can pick out some locations of interest.  I did so, and
came up with this filename spec:

America/{Los_Angeles,Phoenix,Mexico_City,New_York,Toronto,Sao_Paulo} 
Europe/{London,Berlin,Oslo,Moscow} 
Asia/{Calcutta,Shanghai,Tokyo} 
Australia/{Perth,Melbourne} 
Pacific/Auckland

That's actually 16 famous places strewn around the world.  Check your
Linux system, and you'll find the files for each, describing how time
has worked over the years in each city's vicinity.  Turns out, the 
timezone management software built into all *ix systems has a neat
little utility called zdump, that can be run with a timezone description
file as an argument, and it'll report current time there.  So, I added 
to my /home/rick/.bashrc this handy shell alias, 'worldclock':

    alias worldclock='zdump America/{Los_Angeles,Phoenix,Mexico_City,New_York,Toronto,Sao_Paulo} Europe/{London,Berlin,Oslo,Moscow} Asia/{Calcutta,Shanghai,Tokyo} Australia/{Perth,Melbourne} Pacific/Auckland'

The result is that typing "worldclock' at the shell prompt reports
current time at all 16 places.  Example:

$ worldclock
America/Los_Angeles  Sun Feb  7 22:08:39 2021 PST
America/Phoenix      Sun Feb  7 23:08:39 2021 MST
America/Mexico_City  Mon Feb  8 00:08:39 2021 CST
America/New_York     Mon Feb  8 01:08:39 2021 EST
America/Toronto      Mon Feb  8 01:08:39 2021 EST
America/Sao_Paulo    Mon Feb  8 04:08:39 2021 BRST
Europe/London        Mon Feb  8 06:08:39 2021 GMT
Europe/Berlin        Mon Feb  8 07:08:39 2021 CET
Europe/Oslo          Mon Feb  8 07:08:39 2021 CET
Europe/Moscow        Mon Feb  8 09:08:39 2021 MSK
Asia/Calcutta        Mon Feb  8 11:38:39 2021 IST
Asia/Shanghai        Mon Feb  8 14:08:39 2021 CST
Asia/Tokyo           Mon Feb  8 15:08:39 2021 JST
Australia/Perth      Mon Feb  8 14:08:39 2021 WST
Australia/Melbourne  Mon Feb  8 17:08:39 2021 EST
Pacific/Auckland     Mon Feb  8 19:08:39 2021 NZDT
$

 
I think that's kinda neat.  But it is not a solution to the _original_
problem, just to one a bit like it.


But I was onto the right track, which was to use the painstakingly
maintained faclities in any *ix about the world's ridiculously
complicated timezones setup, including all the insanity about exception
and Daylight Saving Time going on and off at different dates in
different places -- and also the plain ol' system 'date' aka date(1) 
utility from GNU coreutils.

And, again, I banged my head against date(1)'s (/bin/date's)
unwillingness to do The Right Thing for a while, and Michael and I had
some discussion.  He pointed me, in passing, to a page that gives the 
best apparent general solution:
https://crashcourse.housegordon.org/gnu-date-timezones.html

  Convert a different timezone to local time

  When it’s 7am in Singapore, what is the local time here?

  $ date -d 'TZ="Asia/Singapore" 2017-09-17 7am'
  Sat Sep 16 17:00:00 MDT 2017    # Your result will vary based on your local timezone
  $ 

  To convert another timezone to your local time zone, set the input TZ
  variable inside the -d date string argument.

Et voila.

That's kind of as good as it gets without writing a wrapper (Perl,
Python, etc.).  The nested quotation marks must be as shown or the date
utility will give up in confusion.  And there are other gotchas, noted
on that page, e.g., if you give the name of a timezone specifier
slightly wrong, the 'date' utility will silently ignore the erroneous
input and act as if you specified UTC.  (Ugh.)

The page also warns against taking shortcuts that assume that timezones
behave rationally and predictably in code.  (Oh no, Grasshopper, no!)

Example given:  Let's say you have buddies in Sydney, Australia, and
knew its timezone is UTC+10.  You know that you're in Pacific Zone,
which (in an excess of confidence) you know is UTC-8.  Also, you 
read somewhere that you can avert that nested-quotation nonsense by just 
putting the remote timezone as a suffix number of hours after the time
there to be converted.  Well then!  Wanting to know what time it will be 
here when it's 7am in Sydney on Tuesday, Feb. 16th, you try:

  $ TZ=UTC8 date -d '2021-02-16 07:00+10'
  Mon Feb 15 13:00:00 UTC 2021
  $

Success!  Or is it?

Your incantation assumes (in effect) that it's Stanard Time (UTC-8) here
in California.  Sure, it's that now, but it isn't for the summer months,
when we're in the PDT timezone (UTC-7).  And what about Sydney?  UTC+10 
is great when Sydney is on Australian Eastern Standard Time (AEST), but
not during the Southern Hemisphere summer months (like right now) when
it's on Australian Eastern Daylight Time (UTC+11).

This illustrates why the page says "Explicit zone hours are not
recommended, as they ignore possible daylight-saving-time changes."
Indeed.

The recommended syntax:

  $ date -d 'TZ="Australia/Sydney" 2021-02-16 7am'
  Mon Feb 15 12:00:00 PST 2021
  $ 

This not only gives the correct answer _now_ (correctly using timezone 
AEDT on the Australian end) but also would adapt correctly at any time
of year, too.

The syntax sadly remains a bit persnickety, but OTOH it works.  In all
cases.  Of course, it's on you to use a correct and relevant timezone
name.  Those live where I mentioned above.  (There are lots of them.
See the discussion on CABAL's mailing list for some of the reasons why.)


-- 
Cheers,                         "2021 showed up, and told 2020 'hold my beer.'"
Rick Moen                                                   -- @justinaireland
rick at linuxmafia.com
McQ! (4x80)