|
このページは大阪弁化フィルタによって翻訳生成されたんですわ。 |
Quoting Syeed Ali (syeedali at syeedali.com): > > Saturday, Nov. 13, 4pm to midnight > > For those of us online, they are west coast. > > This calculator will help with time zones: > > https://www.timeanddate.com/worldclock/converter.html?iso=20211114T000000&p1=234&p2=75&p3=64&p4=179 I stand gently reproved. Thanks, Syeed, I'll remember to include PST/PDT (and perhaps also the UTC offset[1]) in future announcements. BTW, you can find how to solve this problem using only GNU date(1) on balug.org/covid (shortened URL for a BALUG wiki page listing known anglophone online LUG meetings). Yr. humble servant wrote section "#timezone_conversion" near page bottom, giving the recipe. Basically: TZ='[destination zone]' date -d 'TZ="[source zone]" YYYY-MM-DD HH:MM' (where HH is in 24-hour notation). The tricky bit is knowing the correct tzdata[2] specifier for a given location, e.g., knowing that the correct specifier for a LUG in Arizona is America/Phoenix. For that reason, I've made sure correct TZ specifiers are included for all LUGs on that page. [1] The irony in this being that familiar incantations like "PST8PDT", although valid for use by GNU date(1)'s lookup of tzdata database information, it is deprecated for reasons I used to know but cannot currently recall[3], which is why the wiki page states, instead, the recommended TZ="America/Los_Angeles" for San Francisco Bay Area LUGs. [2] https://en.wikipedia.org/wiki/Tz_database https://www.iana.org/time-zones [3] Er, it's something like "Those three-or-four letter tzdata specifiers are neither standardised nor unique, e.g., BST doesn't just stand for British Summer Time but also for Bangladesh Standard, Brazil Standard Time, etc." https://stackoverflow.com/questions/28548750/java-date-forcing-bst-timezone