Yes, they forecast thousands of U.S. elections and thousands of sports games, and their forecasts had excellent calibration—e.g., events they said would happen 30% of the time actually happened about 30% of the time.
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.
Speak for yourself. That's not why I read FiveThirtyEight.
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 performed only slightly better than what you could find in any other reputable newspaper
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.
Trump's second-term clemencies so far have forgiven criminal debts of more than $1.5 billion. That's over 2,000x the amount amount eliminated by Biden's pardons ($680,000).
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.
If all your experience comes from Apollo Client and Apollo Server, as the author's does, then your opinion is more about Apollo than it is about GraphQL.
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.
> I think in this case Europe/Kyiv would actually change its UTC offset to match Europe/Moscow, which I'm pretty sure the TZ database would handle just fine.
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.
> Appointments become past events. Sounds like an operational nightmare to convert all of them right as they become past events.
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.
Past events should just be stored as instants, not as a local time plus location or time zone.
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.
Evan Siroky's Timezone Boundary Builder[0] is a good source of time zone boundary mappings. It can be used via a library in nearly any language you would want[1], or loaded directly into Postgres and used with PostGIS in queries[2] (of course, if you load it into your DB you should have a process for keeping it updated).
It would be wonderful if Jiff supported coordinates-to-tz lookups out of the box :)
The events in question happen at a physical location at a local time, and so are stored as a local time plus longitude and latitude.
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.
The consequences could look something like 50 shift workers showing up an hour late one day, or a user missing a critical meeting.
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.
A future appointment at a physical location is usually an agreement between two or more humans. Humans generally don’t use UTC for future physical events, nor they use a time in a named time zone. What they use is a local time and location (often an address).
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.
That is not quite right. In Postgres, timestamptz (aka timestamp with time zone) represents an instant in time. timestamp (aka timestamp without time zone) represents what you are calling local time. timestamp (without time zone) is exactly what you should use to store future appointments.
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.
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.
Good point. As you mention, that doesn’t matter in this case, as even if a new named time zone is added, the stored named time zone would’ve been written before Europe/Dnipro was created (in case anyone’s wondering why this doesn’t invalidate the point).
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.
No. Local time should nearly always be used to represent the time of future physical events (along side a geographical location, such as an address).
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.