FWIW I'm 43 and grew up on the dark parts of the internet.

The interesting discussion is how much you should take off the table if the offer is uncapped.

If you're trying to expand polynomials and you constantly have to re-derive multiplication from first principles, you're never going to make any progress on expanding polynomials.

And that's the point. Maybe I'm pretty well off but $15/day is still painful for me to drive in every day. But! Occasionally I REALLY need to drive my car in to the city, so instead of driving in five times/week I just drive in once/week. That's 80% fewer trips, a huge reduction.

Doesn't that basically describe access to all scarce resources?

If you don't like the idea of money being used as a way to allocate scarce resources then another way to look at it is forcing people to pay for negative externalities (traffic, pollution). And I don't see why poor people should have to pay less for creating the same negative externalities.

> Why should my taxes get used to build infrastructure that's going to be subjected to congestion pricing that prices me out of using that infrastructure?

I think the arguments here are

1. Rich people pay a much higher percentage of the cost of the infrastructure. If you're so poor then you might not be paying for any of it anyway.

2. You still benefit from the infrastructure - fire trucks, police cars and deliveries are all using the roads to your benefit, even if you don't even drive on them

3. This is very similar to someone saying "why should I pay for roads when I don't own a car?"

4. It's also similar to "why should I pay for schools when I don't have a kid?" These things better society as a whole even if you don't use them directly*

To see what I mean, click "Creating a Feature" then start scrolling up. Notice that "Creating a Feature" is still highlighted even though the entire screen is made up of text from the "Software" section.

I probably only noticed this because I recently implemented a similar "active anchor" solution with Intersection Observer.

If I say I want something to happen at 8pm New York City time on January 7, 2028 and then the DST rules for NYC change, I likely still want it to happen at 8pm. Converting to UTC and back to local time loses that information and it will happen at the wrong time.

Like you said, you're probably bad at predicting which code is going to need changes in the future, so if it's working now and you don't need to change it then it's a silly risk to try to improve it right now.

Lots of situations where resolving the rights issues is going to cost more than you expect the movie to bring in, especially once you start talking about splitting the revenue with online storefronts.

When WB started all this it wasn't clear what the winning strategy was going to be. Now that it is clearer, they're just following.

Right - date-times in the past are always easy (at least until you have to take relativity into account). An event happened at some instant in the universe and you just need an agreed upon representation of that instant. UTC works fine for this - record the UTC-based instant at which the event happened and you can always translate it into any other representation without losing information. Recording it in your local timezone is fine too, as long as you also record the UTC offset or timezone along with the instant.

> I guess it should be detectable which dates may be ambiguous/wrong if you know the date of their creation (before the change was known)

Yeah - in theory, when a timezone is added, you could probably link it to timezones that users of the new timezone might have previously used. And then any future times that were saved using that timezone, you ask someone if they are still correct or if the timezone needs to be adjusted to the new one

For example, if a new timezone was added for southeast Colorado, you might ask someone about all times scheduled in both the Denver & Phoenix timezones, because you don't know which one people might have picked.

It gets complicated though because you need to keep track of which entries have been double checked and which ones haven't, and you need to keep track of the version of tzdb that you reconciled against, because there could be another change in the future.

It's actually easier to create this problem than by bisecting a city, and the easier way is even more complex than bisecting a city.

You obviously can't put every hamlet, town and village into tzdb, for a lot of reasons. So, if you're trying to represent a time in a place that isn't in tzdb, you have to pick the nearest location that is in tzdb. And it's quite possible that between when you enter your time and when that time comes to pass, the location you were specifying for changes it's rules in a way that's different from the original place you chose.

If you bisect a city, you could create two new names, so that if you encountered the old name you'd know that something needed to be reconciled. But if you chose the nearest place and then your rules changed, you'd have no way to know automatically that it needed to be revisited.

For example, parts of Chile decided not to do DST any more. To support this, a new timezone, America/Punta_Arenas, was added to tzdb. Before this, if you were in Punta Arenas, you would just put all your times as America/Santiago. And now you have no way of knowing if those times are really supposed to be Santiago or if they were Punta Arenas and Santiago was just the best you could do at the time.

Location-based tz's are the best we can do right now but even still they have intractable problems when things change.

https://medium.com/servicios-a0/on-solving-the-tzdb-changes-...

https://github.com/tc39/proposal-canonical-tz - appropriately to these comments, a proposal to handle tzdb changes, built on top of JS Temporal, includes some great examples of all the ways this can happen

For Firebase, their costs are probably pretty marginal.

Not saying it’s a good thing but assume that most websites are recording your session at this point.

The fun of my family group chat is reading the messages from everyone.