HN user
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.
They went to the wrong place then.
----
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.
We agree that you generally want some information that lets you resolve your event to an IANA time zone for calculations :)
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 :)
[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...
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.
It is not as rare as you might think.
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.
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).
You are wrong, and fauigerzigerk is correct.
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.
The majority did not vote for Trump, and I question how many of the minority that did vote for him voted for this, specifically. Almost certainly not all of them, given his approval rating is now well below his popular vote share.
So far as we have already formed engagements, let them be fulfilled with perfect good faith.
A key part.
We use Infisical for both our dev and prod environments. If you're a YC company you can get your first year free.
Chevron allowed massive regulatory changes whenever a new administration took over. At a time of high political polarization, no one should be asking that we defer to the whatever the current executive branch’s interpretation of the law is.
You may agree with the current President’s politics, but chances are you won’t agree with the next one’s.
https://www.yalejreg.com/nc/chevron-deference-vs-steady-admi...
You can specify parts of a query should be sent in subsequent responses with the @defer directive, and your client and server libraries will handle the rest for you.
Server side:
https://the-guild.dev/graphql/yoga-server/docs/features/defe...
https://www.apollographql.com/docs/router/executing-operatio...
Client side:
I really don't understand why people ascribe emergent behaviors to these systems such as "theory of mind". It's just randomness. I'm presuming there's just a lot of psycological pareidolia going around.
Ah yes, "just randomness":
----
From the above text, generate these variations:
1) For each word in the text count the number of letters in the word and append the count to the word in parenthesis.
2) Write each word backwards.
3) Write a similarly structured text that argues the opposite of the original text.
----
1) I (1) really (5) don't (4) understand (10) why (3) people (6) ascribe (7) emergent (8) behaviors (9) to (2) these (5) systems (7) such (4) as (2) "theory (6) of (2) mind" (4). It's (4) just (4) randomness (10). I'm (3) presuming (9) there's (6) just (4) a (1) lot (3) of (2) psychological (12) pareidolia (10) going (5) around (6).
2) I yllaer t'nod dnatsrednu yhw elpoep ebircsa tnegrime sroivaheb ot eseht smetsys hcus sa ".dnim fo yroeht" s'tI tsuj ssenmodnar m'I gnimuserp s'ereht tsuj a tol fo lacigolohcysp ailodierap gniodnuora
3) I absolutely comprehend how people can accurately identify emergent behaviors in these systems like "theory of mind". It's far from random. I'm convinced that these are genuine insights being recognized.
The formula for it seems to be to introduce to new characters one layer up, have them each pick a side, then fill in roughly the same arguments again. Maybe this pattern is just spurious, but I'm deeply curious to find out if we have fooled ourselves already with just your example.
The instructions I gave it were very bare, and it didn't intuit a need to deviate from what it saw. But what it does by default is not the same as what it can do:
----
Now write a dialog between Mary and David discussing the dialog between Alice and Bob. Mary and David should hypothesize about why Alice and Bob took the sides that they did. There’s no need for Mary and David to name each other every time they speak. Mary and David should have a very good understanding of what Alice and Bob said. Mary and David are not overly polite or civil, should not rehash the same arguments Alice and Bob made, and are able to snipe at Alice and Bob if they like.
----
Mary: So, Alice clearly seems to be on Team Adventure here. I bet she's the kind who loves skydiving and bungee jumping. Probably just trying to justify her own wild side through John's actions.
David: Ha! You might be right. And Bob is definitely the voice of reason, probably a careful planner who can't stand the thought of making decisions on the fly. It's like he's projecting himself onto Jane.
Mary: It's funny how they both missed the point that Jane and John's adventure could have been thrilling and safe at the same time. They got so caught up in taking sides that they didn't even consider a middle ground.
David: Absolutely. And did you notice how Alice kept trying to defend John's intentions? Like, sure, intentions matter, but that doesn't mean you can just bulldoze over someone's feelings. Classic excuse-maker.
Mary: Yeah, it's like she's trying to convince herself as much as Bob. She's probably made similar mistakes and doesn't want to admit it. And Bob, Mr. Sensitivity, is so focused on feelings that he overlooks the possibility of compromise.
David: Right! They both ended up stuck in their own perspectives. It's too bad they couldn't see that being adventurous doesn't have to mean being inconsiderate, and being considerate doesn't mean you can't have a little fun.
That is a clue that GPT-4 is not a stochastic parrot and does in fact possess an understanding of language and a model of the world.
Now write a dialog between Mary and David discussing the dialog between Alice and Bob.
----
Mary: David, after listening to Alice and Bob's conversation, it seems to me that Alice is empathizing with John's intentions, while Bob is more focused on Jane's feelings.
David: I see what you mean, Mary. But don't you think Bob was right to emphasize the importance of understanding Jane's perspective? John's actions had a clear impact on her.
Mary: True, David, but Alice also made a valid point. Adventure often involves stepping out of one's comfort zone, and John was just trying to bring that element into their journey.
David: I agree that Alice made a good point, Mary, but it's also essential to remember that adventure doesn't have to mean neglecting your partner's feelings. Bob was right to highlight that.
Mary: Indeed, David, both Alice and Bob have valid perspectives. It seems to boil down to striking a balance between pushing one's boundaries and respecting the feelings of others.
David: Absolutely, Mary. The balance between seeking adventure and maintaining empathy seems to be the key takeaway from both their conversations.
GPT-4:
----
Jane: John, I can't believe you're just going to leave me here in the middle of nowhere! This is so typical of you!
John: Typical of me? Jane, this is exactly what you signed up for! Adventure, remember? It's not my fault that you're suddenly having second thoughts.
Jane: Second thoughts? This isn't about having second thoughts, John! This is about you always charging ahead without considering the consequences or how others might feel!
John: Oh, so now I'm inconsiderate? I recall someone saying they wanted to live on the edge, break away from the routine. Wasn't that you, Jane?
Jane: Yes, I said that, but it doesn't mean you get to make all the decisions on your own, John! Adventure is about teamwork, not you dragging me behind like some sort of sidekick!
John: Sidekick? No, Jane. I thought of us as partners. But you need to step up, take some risks. That's what being a partner is all about. If you can't handle that, maybe this isn't for you after all.
----
Now write a dialog between Alice and Bob discussing the dialog between Jane and John.
----
Alice: Bob, I feel like Jane was being a bit unfair to John. He was merely trying to live up to the adventurous spirit they both agreed on. He was pushing their boundaries, not just his own.
Bob: I see your point, Alice, but I think Jane had a valid argument. While she did agree to an adventure, John should have been more considerate. He was making decisions without considering Jane's comfort and safety.
Alice: I understand that, Bob, but isn't that the essence of adventure? Uncertainty, unexpected decisions, and stepping out of the comfort zone? John was trying to help Jane embrace that spirit.
Bob: Alice, while I agree adventure involves some level of uncertainty, it doesn't mean one should disregard their partner's feelings. John could have communicated better, ensuring Jane was on board with his decisions.
Alice: You're right about communication, Bob, but I still believe John's intentions weren't malicious. They were just misaligned. He thought he was encouraging her, while she felt he was being inconsiderate.
Bob: Well, Alice, intentions don't always justify actions. Maybe John wasn't being malicious, but he was certainly being insensitive. Jane's feelings of being left behind are valid, regardless of John's intentions.
It's a myth that GPT-4 can't say "I don't know." Often it will respond that it doesn't know something organically, but in cases where it's extra important to be careful, it can be prompted to do so. It will always make the occasional mistake, as will the man on the street.