[conspire] (forw) [sf-lug] Timezone trouble (was: Virtual meeting of Sunday February 7, 2021)
Rick Moen
rick at linuxmafia.com
Sun Feb 7 23:04:15 PST 2021
----- Forwarded message from Rick Moen <rick at linuxmafia.com> -----
Date: Sun, 7 Feb 2021 22:44:50 -0800
From: Rick Moen <rick at linuxmafia.com>
To: sf-lug at linuxmafia.com
Subject: [sf-lug] Timezone trouble (was: Virtual meeting of Sunday February
7, 2021)
Organization: If you lived here, you'd be $HOME already.
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)
_______________________________________________
sf-lug mailing list
sf-lug at linuxmafia.com
http://linuxmafia.com/mailman/listinfo/sf-lug
SF-LUG is at http://www.sf-lug.org/
----- End forwarded message -----
More information about the conspire
mailing list