stop storing future dates in UTC

[bhearsum]

Nick pointed out this series of tweets (https://twitter.com/tef_ebooks/status/949350236392181760?s=03) which explains that it's not safe to store future dates in UTC, because local timezone offsets shift around with DST, while UTC does not. This means that if someone in North America schedule's a change 2 days before a DST change, but we schedule it to take place 2 days AFTER the DST change (aka 4 days in the future) - it will end up being off by an hour.

The thread recommends storing future dates as time + named timezone (that is, "US/Los_Angeles" - or something like that), because timezones ("PST") can change in the future too.

I think this has a couple of implications for Balrog:

• We should absolutely stop storing scheduled change times as UTC. We should probably store as Mountain View time ("US/San_Francisco" probably), since that is considered to be Mozilla Standard Time.
• Scheduled Changes should be required to be submitted in this timezone. This will prevent issues if someone in a different timezone, which has different DST rules, submits a Scheduled Change near a California DST-change day. We should also only display this timezone when presenting Scheduled Changes for the same reason.

There may be other necessary changes, too.

I think history tables are unaffected by this (I don't think that timezones or DST can retroactively be changed), but we may want to consider storing history in the same timezone for consistency. History UI can almost certainly be presented as user-local time regardless of what we do on the backend.

(Imported from https://bugzilla.mozilla.org/show_bug.cgi?id=1431793)

For posterity, the aforementioned tweets:

psa: you can’t store future dates as UTC because local time offsets can and will change
and you can't store time zones as utc offsets because dst rules change too
if a user can pick the time, and it could be in the future, I'm sorry, you can't normalise to utc
what you want to store, isn’t timezone offset, or name, but location

or why tzinfo uses ‘US/Los_Angeles’ as the key
normalising future dates to utc or offset, or even storing ‘PST’ means ignoring dst or local timezone changes you need ‘US/Los_Angeles’