Automatically select timezone based on venue location

[timreyn]

Is your feature request related to a problem? Please describe. The most common time zone used for US competition venues is...

mysql> select timezone_id, count(1) from competition_venues join Competitions on competition_id = Competitions.id where countryId="USA" group by 1 order by 2 desc;
+------------------------------+----------+
| timezone_id                  | count(1) |
+------------------------------+----------+
| America/Adak                 |      111 |
| America/New_York             |       53 |
| America/Chicago              |       37 |
| America/Los_Angeles          |       28 |
| America/Denver               |        9 |
| America/Detroit              |        4 |
| America/Phoenix              |        3 |
| America/Boise                |        3 |
| America/Kentucky/Louisville  |        3 |
| America/Indiana/Indianapolis |        2 |
| America/North_Dakota/Center  |        1 |
+------------------------------+----------+
11 rows in set (0.01 sec)

America/Adak! It's a small timezone in the Aleutian Islands in Alaska, with about 8,000 residents. America/Adak is also the first timezone alphabetically. I'm guessing many organizers see America, don't know what Adak is, and nothing tells them they're doing something wrong.

This means that any application of WCIF data which uses the schedule will be off by 4-7 hours for half of US competitions.

Describe the solution you'd like Here's a gem that converts lat/long to timezone: https://github.com/panthomakos/timezone We could use this rather than having the organizer pick the time zone.

[jfly]

Autoselecting the right timezone feels like a good long term solution. As a short term solution, I think it would make sense to force the user to pick a timezone. I've made that change over in https://github.com/thewca/worldcubeassociation.org/pull/4503.

[AlbertoPdRF]

Together with #4503, should we contact the Delegates that may have picked a wrong timezone and ask them to check/correct it?

[jfly]

@timreyn, do you think it would be better to reach out to delegates and ask them to fix this, or for us to instead just fix this as best we can based on the lat/long of the competition?

[timreyn]

I think we should fix this ourselves, once we switch to automatically picking time zones and have code in place for converting lat/long to timezone. I don't think this is critical enough that we need to ask all delegates to fix this manually before we can do it automatically.

[jamesquinn1]

Somewhat unrelated, but is there an explanation for what time zones are options? There's 7 time zones for Indiana as options, and 3 for North Dakota and that seems quite random and unneeded, and makes the list of time zones far longer than it needs to be.

[timreyn]

Yeah, this is a gap between "how programmers think about time zones" and "how real people think about time zones". We're using a thing called tz database (https://en.wikipedia.org/wiki/Tz_database).

This gets complicated for places like Indiana. Indiana has moved counties around a few times (https://en.wikipedia.org/wiki/Time_in_Indiana). e.g. Pulaski County switched from Eastern to Central for a year, and then went back, so if you just said "eastern time" instead of "America/Indiana/Winamac" then you'd get times wrong from April 2, 2006 to March 11, 2007.

I think this would all be easier if we didn't make people think about it, and just selected the right time zone automatically :)

[timreyn]

See also http://www.creativedeletion.com/2015/01/28/falsehoods-programmers-date-time-zones.html

[Samuel-Baird]

What about multi-location fmc competitions? Maybe this could be on by default but organizers have the ability to toggle it off.

Edit: didn’t know that it’s now possible to switch schedules for locations :P

[timreyn]

Each venue has its own timezone. For a multi-location FMC competition, each venue would have its timezone selected automatically.