----

Nov. 1, 2016 — Election Update: Yes, Donald Trump Has A Path To Victory — https://archive.is/kwdab

> Tuesday was another pretty good day of polling for Donald Trump.

> Trump remains an underdog, but no longer really a longshot: His Electoral College chances are 29 percent in our polls-only model — his highest probability since Oct. 2 — and 30 percent in polls-plus.

> This isn’t a secure map for Clinton at all. In a race where the popular vote is roughly tied nationally, Colorado and New Hampshire are toss-ups, and Clinton’s chances are only 60 to 65 percent in Wisconsin, Michigan and Pennsylvania.

> If you want to debate a campaign’s geographic planning, Hillary Clinton spending time in Arizona is a much worse decision than Trump hanging out in Michigan or Wisconsin.

----

Sept. 16, 2016 — How Trump Could Win The White House While Losing The Popular Vote — https://archive.is/rxP5l

> Using a prototype of a demographic election calculator that FiveThirtyEight will be unveiling in the next few weeks, I decided to simulate a few election scenarios.

> The result? Clinton would carry the popular vote by 1.5 percentage points. However, Trump would win the Electoral College with 280 votes by holding all 24 Romney states and flipping Florida, Ohio, Pennsylvania, Iowa and Maine’s 2nd Congressional District from blue to red.

----

Jun 29, 2016 — Donald Trump Has A 20 Percent Chance Of Becoming President — https://archive.ph/ryIkP

> A 20 percent or 25 percent chance of Trump winning is an awfully long way from 2 percent, or 0.02 percent. It’s a real chance: about the same chance that the visiting team has when it trails by a run in the top of the eighth inning in a Major League Baseball game. If you’ve been following politics or sports over the past couple of years, I hope it’s been imprinted onto your brain that those purported long shots — sometimes much longer shots than Trump — sometimes come through.

----

FiveThirtyEight was probably the worst reputable source to read if you were looking for maximum assurances that Clinton would win.

The purpose of FiveThirtyEight was never to be an oracle for the average person. It was always a deliberately wonky site for a wonky audience. They were very clear about that in the articles they published and topics they covered.

FiveThirtyEight gave Trump double the odds of the next highest reputable prediction, which was The New York Times Upshot (15%). Princeton Election Consortium gave Trump less than 1%.

That is not "only slightly better" to anyone who's statistically literate.

A FiveThirtyEight reader in 2016 was significantly better calibrated regarding Clinton’s chances than a reader of other reputable newspapers.

These pardons go to convicted criminals who have ties to Trump and his administration, or who have donated significant sums to Trump.

It is very obvious the current administrating is the most corrupt administration in modern history by several orders of magnitude.

https://www.cato.org/blog/embarrassment-riches

You should be using Relay[0] or Isograph[1] on the frontend, and Pothos[2] on the backend (if using Node), to truly experience the benefits of GraphQL.

[0]: https://relay.dev/

[1]: https://isograph.dev/

[2]: https://pothos-graphql.dev/

Another user has already responded to the rest of your comment, so I’ll just respond to this.

In the Ukraine scenario Russia does not control Kyiv, so no, Europe/Kyiv would not change its offset.

That is fair. In some models there's a natural separation between a scheduled-at time and a happened-at time (e.g., in one I worked on scheduled_events was a separate table from past_events), but I accept that's certainly not all, or even most. I shouldn't have made such a blanket statement. I do believe the statement is good advice in cases where your data does not mix both future and past times.

> Sometimes those costs are worth it, but certainly not for every use case.

This is also fair. My experience with time zones has been the more correct I can make my time models, the better I sleep at night, but of course you're right engineering involves tradeoffs. I think it's important to at least know the most correct way so that you are making educated decisions in your tradeoffs.

Also, FWIW I'm not the person you originally replied to, although the Ukraine example was mine.

Further, I believe the historical data is meant to be handled by the named time zone, so Russia moving Dnipro to MSK would create a new time zone, call it Europe/Dnipro, then Ukraine reacquiring the territory and moving it back to EET would keep (or further split) Europe/Dnipro, and the historical changes of Dnipro would be handled by tzdb.

So even if you did store past events with a local time plus a location (which you should not do), I don't think Ukraine reacquiring the territory would cause problems, although we're really stretching my knowledge of IANA named zones and I could certainly be wrong.

It would be wonderful if Jiff supported coordinates-to-tz lookups out of the box :)

[0]: https://github.com/evansiroky/timezone-boundary-builder/rele...

[1]: https://github.com/evansiroky/timezone-boundary-builder#look...

[2]: https://www.crunchydata.com/blog/timezone-transformation-usi...

If they were stored as instants, and then if a location moved time zones or stopped using DST in the summer, the event’s stored time relative to the expected local time would incorrectly shift.

Dealing with and debugging time zones is already such a confusing mess that I find that anything that makes your application more correct with regards to time zones is worth it. The important thing though is knowing, and then you can make an informed decision on how may shortcuts you want to take with time zones.

If you’re writing software that’s only designed to be used in a small region or by just a few people, then sure, it’s probably not super important.

If you’re writing software that’s used all over the map in places and time zones you can’t predict, well, it helps me sleep better at night.

fauigerzigerk is saying that this, among with others, is the use case for what they are calling “local time,” what you are calling “nominal time,” what Postgres calls “timestamp without time zone,” and what the JS Temporal API calls “ PlainDateTime.”

In my experience engineers not understanding this key point, and believing that zoned time should be used for everything, is its own cause of issues and confusion.

Something that often trips people up is that they think timestamptz stores a timestamp plus a time zone (probably because of its unfortunate name). It does not; it always stores a Unix epoch without an extra time zone, converting any zoned timestamp that it is passed.

The most recent time this happened was March of this year, with Chile's Aysén Region dropping DST and moving to the newly created America/Coyhaique.

https://data.iana.org/time-zones/tzdb/NEWS

I used to manage a large application for scheduling shifts at warehouses in many different locations, and storing future events as local timestamps and lazily converting them just before calculations into their location’s zoned time was the only way I could stay sane.

Future physical events, such as an appointment at a physical location, should be stored as unzoned time plus a location (such as an address), NOT with a named time zone.

This is because physical locations can change named time zones due to political reasons (this has happened many times already).

Storing an appointment time with “Europe/London” only works if your appointment is actually in London and not some other British city (and even that assumes that London never gets divided in the future).

If I say meet me in person at 10am March 5th, 2030 in Dnipro, Ukraine, that's specific to a location, not Europe/Kyiv.

Why? Because perhaps in 2030 Russia has taken over Dnipro and moved it from Europe/Kyiv to Europe/Moscow.

Our meeting time has obviously not changed, but its exact instant on the universal timeline has changed.

This is super important to get right and you are spreading incorrect information that, if followed, will lead to bugs.

Your method of using a named time zone like “Europe/London” is generally wrong for future physical events, and leads to bugs if and when the actual physical location of the event changes named time zones (which does happen).

If I say meet me in person at 10am March 5th, 2030 in Dnipro, Ukraine, that's specific to a location, not a named time zone.

Why? Because perhaps in 2030 Russia has taken over Dnipro and moved it from Europe/Kyiv to Europe/Moscow.

Our meeting time has obviously not changed, but its exact instant on the universal timeline has changed.

Physical future events are not a fixed instant on the universal timeline, they are a local time + a location.

A key part.