Skip to content

change TZ value from UTC (which causes blocks) to use a real-world-used TZ

See:

Since UTC is rare (if not non-existent outside of RFP?) it looks as if this is being used as a blocker in some anti-bot scripts etc, and while TB and RFP are not trying to hide, it's not ideal to use non-common values for compat reasons - not that this is compat. UTC is unique (with Factory which is just as rare if even used) as a stable all-year-round, all-years measurement for other dates (which usually also have DTS) to be compared to. That is, only UTC is always offset as 0 (which makes sense). This made it easy and simple for users to calculate their real time on sites - e.g. sporting event times

Using an amazing tool I found on the internet, tests reveal that there are 13 real-world TZs being used that are identical since 1912, and only off by 16.3333 minutes prior to that

item 1

    <snip> UTC <snip>
    a54eb173
    1911: 0, 0
    1912: 0, 0

item 10

    Africa/Abidjan, Africa/Accra, Africa/Bamako, Africa/Banjul, Africa/Conakry, Africa/Dakar, Africa/Freetown, Africa/Lome, Africa/Nouakchott, Africa/Ouagadougou, Africa/Timbuktu, Atlantic/Reykjavik, Atlantic/St_Helena
    1911: -16.133333333333333, -16.133333333333333
    1912: 0, 0

If we cover all years, these are still the only differences between these 13 and UTC - i.e pre-1912. PS: I cheated and modified the code to only use those 14 TZs and all years from 0 to 2500 😄

So in theory, we could use one of these (or if we were sneaky we could randomize it per eTLD+1 per session/identity), and users use-cases of recent and future dates (calendars, web email, looking up event times for sports or concerts etc) will still look and behave like UTC. Dates prior to 1912 are unlikely to need or even use conversion to the user's timezone (e.g. history articles etc). And this should stop the anti-bot discrimination

I wonder if we patch that here in MB first? What would users think when they see non-UTC being reported? Will we be flooded with bug reports? Note there are no entropy issues as all users would still look the same. One consideration is timeZoneNames, but that would be equivalency of locale (which we set same as language)

cc @ruihildt @tom @richard to check my logic and proposed solution

Edited by Thorin