> ... but as of 22:28 UTC Facebook appears to be ...
Someone assumed London==UTC, when London is 1 hour ahead :) that was actually 21:28 UTC
Someone assumed London==UTC, when London is 1 hour ahead :) that was actually 21:28 UTC
It's especially annoying when dealing with multiple countries that may or may not be using Daylight Saving Time.
A few weeks ago I tried to find out what the current time in CET is. Asking google for "CET" gave me: "23:27 CET". Asking google for "CET time" (I know that "time" is twice in this case) gave me "00:27 CET".
The last one is wrong and should be CEST or even more correct would be just the same result for CET as I asked for
$ zdump -v Europe/Berlin | grep 2021
Europe/Berlin Sun Mar 28 00:59:59 2021 UT = Sun Mar 28 01:59:59 2021 CET isdst=0 gmtoff=3600
Europe/Berlin Sun Mar 28 01:00:00 2021 UT = Sun Mar 28 03:00:00 2021 CEST isdst=1 gmtoff=7200
Europe/Berlin Sun Oct 31 00:59:59 2021 UT = Sun Oct 31 02:59:59 2021 CEST isdst=1 gmtoff=7200
Europe/Berlin Sun Oct 31 01:00:00 2021 UT = Sun Oct 31 02:00:00 2021 CET isdst=0 gmtoff=3600(And that's not counting daylight savings time, and its varied observance!)
No joke. Today I ended up writing a whole essay explaining the issue I was having and almost sending it off to the core developers because I thought I had discovered an issue with the actual language. The bug was because I had forgot to convert too&from utf-8 in these two procedures:
proc 2Hex { input } { binary encode hex [encoding convertto utf-8 "$input"] }
;# Converts base32 string data to base16
proc 2Base { input } { encoding convertfrom utf-8 [binary decode hex "$input"] }
;# Converts string hex data to base32