[conspire] timezones ...

[Michael Paoli]

> From: "Rick Moen" <rick at linuxmafia.com>
> Subject: Re: [conspire] upcoming_meetings (link)
> Date: Sun, 7 Feb 2021 01:27:04 -0800

> 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.

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 mention Oregon and Washington.  May be some others
too in addition to Southern California that are still in same timezone.

> 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
> $

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.
As I believe there are cases of timezone abbreviations being non-unique,
and in such cases, GNU's data might guess incorrectly as to which timezone.
I think also, somewhere, there's even some timezone FAQ that happens
to cover that point (and lots of other interesting/useful bits too).

> 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.

And, I was thinkin', ought not be too horribly difficult to click on map
and get correct timezone ... at least most of the time anyway ... I think
even Fedora/CentOS/Red Hat's installer has that ... I think the *buntus may
have likewise.  Hmmm, maybe even Debian with GUI installer, but I forget.
In any case, a semi-solved problem? ...
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.
Ah, and an example of non-unique timezone abbreviations:
IST = Indian Standard Time and Irish Summer Time
Thought I spotted a CLI utility that could take latitude/longitude
and get IANA zone from that, which could then be used to get timezone
... but not quite finding now where I'd spotted that.