[conspire] upcoming_meetings (link)

[Rick Moen]

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

> Oh, forgot to include link to the latest:
> https://www.mpaoli.net/~michael/bin/upcoming_meetings
> mostly just leverages perl's Date::Calc

Nice, as always.

The main thing that should be said about
http://www.wiki.balug.org/wiki/doku.php?id=balug:covid-19 is that it's
the best, most useful, and most accurate schedule of upcoming virtual
LUG meetings in existence.

It's also, AFAIK, the _only_ such schedule in existence, but dwelling on
that fact might seem ungrateful.

For the LUGs outside the Bay Area (excepting the two in SoCal), 
trying to use them to determine whether, say, Birmingham LUG's meeting
is in an hour vs. I just missed it becomes, after following Web links, a
timezone math problem.  Nobody's fault.

Brummies (Birminghamers) state their event times in GMT/BST.  Converting
that to PST/PDT (and all of the other myriad crumming local time
regimes) is not their problem.  But that leaves me as a potential
attendee and user of BALUG wiki information needing to grapple with
timezone math.

It's no good memorising 'The UK is eight time zones later than us',
because that's not always true, either -- because it'd be more luck
than we could ever expect for California and the UK to enter and leave
Daylight Saving Time on the same date.  So: timezone math.

Technically, the Birmingham LUG Web site just says "19:30", so the
aspiring virtual traveler needs to infer the right TZ.  Still, it'd be
nice to write or steal a /usr/local/bin/timehere script, so I could do

$ timehere 1930 Europe/London

or, better yet

$ timehere 2021-02-16 1930 Europe/London


Maybe I'll just get used to doing this sort of thing:

$ date -d "2021-02-16 19:30:00 GMT"
Tue Feb 16 11:30:00 PST 2021
$ 

It's kind of good enough, I guess.  A little fiddly, and you need to 
know the right TZ designation and fill it in for the appropriate
DST/non-DST part of the year -- but that's the world's fault, not
Linux's.