[conspire] timezones ...

[Rick Moen]

Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):

> There are others in same timezone outside the Bay Area, at least I
> think so - not only Davis and Sacramento (debatable as to whether or
> not in "Bay Area"), aren't there at least one or two up much farther North
> in California?

Not to my knowledge holding online meetings.  (Don't forget, the context
was trying to use meeting scheduling data on
https://www.wiki.balug.org/wiki/doku.php?id=balug:covid-19 more
efficiently, without zonefile-math transaction costs every time you want
to guesstimate whether it's about time for meeting X.)

> Not to mention Oregon and Washington.  

One, Bellingham LUG.

> May be some others too in addition to Southern California that are
> still in same timezone.

That appears to be it for the wiki page listings, at present.

South America is Right Out, on account of how the continents are
physically aligned.  Pacific Time Zone extends south from the northern
half of Baja California down to a particularly empty stretch of the
South Pacific, catching only a scruffy little island owned my Mexico
(Isla Guadalupe[1]) and an even more scruffy one owned by France (L'île
de Clipperton).  It doesn't even snag Pitcairn Island or Easter Island /
Isla de Pascua / Rapa Nui.  (Both of those are places Deirdre and I have
visited, yay!)

Mind you, I'd gladly handle UTC-9 for Pitcairn, or UTC-7 for Easter
Island, but I doubt that either of those hardy crews is doing Linux on
Jitsi Meet at the moment.

> >$ date -d "2021-02-16 19:30:00 GMT"
> >Tue Feb 16 11:30:00 PST 2021
> >$
> 
> Yes, something like that will probably work most of the time.
> Somewhat more goof-resistant would be doing instead, two steps,
> setting TZ in each step, and using seconds since the epoch as intermediate.

Since (in context of the wiki page) I'm converting _to_ Pacific Time for
purposes of 'How long until the $FOO LUG online meeting?', it seems to
me that TZ need not be set.  (I'm mildly surprised to note that said 
environment variable is normally undefined for my user, but whatever.)
Fortunately, my local system time is correct for where I am in the
world, or I'd have bigger problems.

When I said 'know the right TX designation', I didn't mean _literally_ 
environment variable TZ; I meant 'know the correct timezone applicable
for the distant location where the online LUG meeting will be happening.

[Late edit:  You might be trying to cluebat me into a different use of
variable TZ, and I stumble into that further down this posting.]

E.g., with Birmingham LUG, UK, obvious intuition says their time
reference of 19:30 will be GMT or BST, depending on season.  So, hey,
without software assistance, that permits me to guesstimate the
applicable time offset and be mistaken with confidence if I guess wrong
about whether they're on Summer Time on a particular date.  And you'll
note that my clever-but-stupid solution of 

   date -d "2021-02-16 19:30:00 GMT"

risks that exact blunder.  "Europe/London" would seem intuitively a
better specifier to avoid the Summer Time / no Summer Time pitfall,
but...

   $ date -d "2021-02-16 19:30:00 Europe/London"
   date: invalid date `2021-02-16 19:30:00 Europe/London'
   $ 

...GNU date (part of coreutils) cannot parse it, even though it's a
valid zonefile specifier.  What one ideally wants is the analogue to
timezone "PST8PDT".  Poking around, I find "GB" and "GB-Eire".  (Poor
Northern Ireland; forgotten again.)  Unfortunately:

  $ date -d "2021-02-16 19:30:00 GB"
  date: invalid date `2021-02-16 19:30:00 GB'
  $ date -d "2021-02-16 19:30:00 GB-Eire"
  date: invalid date `2021-02-16 19:30:00 GB-Eire'
  $

The date(1) manpage says that, in addition to numeric timezones, it can
handle:

  %Z     alphabetic time zone abbreviation (e.g., EDT)

Roger that.  But it appears a bit persnickety about the subset of valid
timezones it understands.  But wait...

Lateral thinking, and groping around on the Web, finds this workaround
that _does_ work, and would automagically account for the Greenwich Mean
Time / British Summer Time seasonal switch:

  $ date -d 'TZ="Europe/London" 2021-02-16 19:30:00'
  Tue Feb 16 11:30:00 PST 2021    
  $

...suggested by
https://crashcourse.housegordon.org/gnu-date-timezones.html

So, enfin, that "works", but oy, _what_ a headache.  (Used that way,
"GB" and "GB-Eire" also work.  But of course "UK" does not, because
there is no such named timezone.)


> And, doing wee bit 'o search:
> linux convert (location OR latitude longitude) to timezone
> https://www.google.com/search?q=linux+convert+%28location+OR+latitude+longitude%29+to+timezone
> quickly leads to:
> https://stackoverflow.com/questions/16086962/how-to-get-a-time-zone-from-a-location-using-latitude-and-longitude-coordinates/16086964
> and some of the top "answer"s there look highly informative and useful.
> Looks like a bunch of relevant information can also be found here:
> https://stackoverflow.com/tags/timezone/info
> ... and not limited to *nix.a

Well, seriously, is that a practical approach?  "Computer, I'm hoping to
attend a Zoom conference in Birmmingham.  No, not Alabama, you dork.
West Midlands, UK.  Please determine the latitude and longitude for
Birmingham and calculate a timezone specifier that will be understood by
GNU date."

I guess I'd do that if I had to, but it seems a little wacky.

Speaking of wacky, to see just how utterly insanely complex all of this
can become, read the Wikipedia page on nautical time zones.
https://en.wikipedia.org/wiki/Nautical_time


[1] Isla Guadalupe is at least liveable, but is a biosphere reserve such
that visitors need a permit from the government in Ciudad de Mexico, so
not a tourist destination.  Not that it offers much otherwise other than
two shield volcanos, a few hikes, and lots of good fishing.

By contrast, France's Clipperton Island / L'île de Clipperton is a
barren atoll with fairly ghastly historical tale to tell:
https://www.damninteresting.com/the-tyrant-clipperton-island/