As a maintainer on the Ky team, I give a big thumbs up to this proposal.
We have run into many problems with web streams over the years and solving them has always proven to be hairy, including the unbounded memory growth from response.clone().
The Deno team implemented a stream API inspired by Go, which I was happy with, until they ultimately acquiesced to web streams.
This proposal shares some of those principles as well.
As a passenger, I often think to myself, "Why is the bus stopping here? There was a a stop just two blocks ago." Invariably, the bus then has to wait for someone to move out of the way before it can pull in. It's very inefficient. Stops should be about 10 walking minutes apart at minimum.
I think if the bus has to wait to pull in there's also an outstanding problem there.
Having lived in EUropean cities with both efficient and terrible bus performances, the presence of separate lanes, large unencumbered stops or good urban architecture/road decor makes a significant difference.
I think you’re confusing “haptic” for “capacitive”. The wheels are real, physical controls with motors to give tactile feedback about the state of the UI. You can literally feel where the beginning and end of a list are, for example. It’s even better than traditional buttons.
The only problem is that there aren’t also physical controls for media and climate, which there should be. But for everything else, the thumb wheels are going to be awesome.
Maintainer on the Ky library team here, a popular HTTP client for JavaScript.
We support these headers, but unfortunately there’s a mess of different implementations out there. The names aren’t consistent. The number/date formats aren’t consistent. We occasionally discover new edge cases. The standard is very late to the party. Of course, better late than never. I just hope it can actually gain traction given the inertia of some incompatible implementations.
If you are designing an API, I strongly recommend using `Retry-After` for as long as you can get away with it and only implementing the rate limit headers when it really becomes necessary. Good clients will add jitter and exponential backoff to prevent the thundering herd problem.
We also try to roll a Retry-Limit (max number of retries) header to prevent our clients from hurting our services too much if there are ongoing issues.
Personally, I like that UTC is the default time zone. Processing of dates should happen in a standardized time zone. It’s only when you want to display it that the date should become local.
UTC is a fine default time zone, but that doesn't matter here.
A datetime with a timezone and a datetime without one are two different things, both of them useful. My birthday does not have a time zone. My deadline does.
The company deadline for getting some document returned? It might or might not, that's policy.
Poetically: we are born free of time zones. We die bound to one.
It doesn't to me. It should be obvious that there are plenty of valid uses of dates and times which implicitly refer to either an exact instant in time, or the expression of a time in a certain reckoning.
A birthday doesn't have a time zone because the concept of a birthday is more about the date on the calendar on the wall, not any universally understood singular instant in time; and so what matters most when it comes to your birthday is where you are. Your birthday doesn't move to the day before or after just because you travel to the other side of the globe.
A deadline has a time zone because when your boss says he wants the project done by 4PM, he means 4PM wherever you both currently are -- and the specific instant in time he referred to doesn't change if you get on a train and move a time zone over before that 4PM occurs.
And it may in fact be time zone and not just UTC with an offset; because if your boss tells you he wants a certain report on his desk by 4PM every day; when your local time zone goes into daylight saving time, it doesn't suddenly mean the report needs to be filed by 5PM instead.
In the first of these cases, the date itself has no time zone and is valid in whatever context its being read from. In the second, the instant in time might be expressed in UTC time with or without a specific offset. In the third, each of the successive instants in time may shift around with respect to UTC even while it continues to be referred to with one constant expression.
None of these are subjective interpretations. They're a consequence of the fact that as humans we've overloaded our representation of date/time with multiple meanings.
idk about you but I can get a happy birthday on the hour of my actual birth from people in the know but I never literally prepare things for the exact hour of the deadline. It's more like a day sort of thing
It does not. I'm Australian and our timezones are ahead of the US (NSW time is about 15-17 hours ahead of US Eastern time). If I took a flight from Sydney to New York (22~ hours) on my birthday, the US custom's officer would wish me happy birthday when I landed the next day.
Therefore, birthdays are not bound by timezone at all.
This will result in incorrect behavior when, between converting to UTC and back to the original timezone, the timezone database has changed, which happens more often than you think.
Depends what you're actually storing. There are plenty of cases where the timezone is not metadata; it defines how the datetime should be interpreted.
For example: your local mom and pop corner store's daily opening and closing times. Storing those in UTC is not correct because mom and pop don't open and close their store based on UTC time. They open and close it based on the local time zone.
You conflate different concepts here. The actual moment of opening and closing can be stored in UTC, because it's proper time. Scheduling algorithm is an algorithm, not time. You can use DSL similar to time to code this algorithm, but being DSL it can go only so far to implement it.
You don't need to store the timezone anywhere, you just need to know the current local timezone when the stored UTC time is used. And that's why storing in UTC is better, because it only takes one conversion to represent it in some arbitrary local time.
If you stored it as a local time (ie: with TZ), then if it's ever later translated to a different local time (different TZ), you're now dealing with all the quirks of 2 different timezones. It's great way to be off by some multiple of 15 minutes, or even a day or two!
Heck, even if it's the same exact location, storing in local time can still require conversion if that location uses daylight savings! You're never safe from needing to adapt to timezones, so storing datetimes in the most universal format is pretty much always the best thing to do.
I started looking at self-hosting many applications at home once I realized that IPv6 could enable me to do that securely without any complicated router/firewall configuration that would need to be maintained.
The only wrinkle I ran into is that apparently ISPs are still reluctant to give out static IPv6 prefixes to residential customers. So you still need some kind of DDNS setup, which is lame.
When people say “creator’s intent”, it sounds like a flavor. Like how food comes out of the kitchen before you put toppings on it to make it your own.
But vivid mode (et al) literally loses information. When the TV tries to make everything look vibrant, it’s effectively squishing all of the colors into a smaller color space. You may not be able to even tell two distinct objects apart because everything is similarly bright and vibrant.
Same with audio. The famous “smile” EQ can cause some instruments to disappear, such as woodwinds.
At the end of the day, media is for enjoyment and much of it is subjective, so fine do what you need to do to be happy. But few people would deliberately choose lower resolution (except maybe for nostalgia), which is what a lot of the fancy settings end up doing.
Get a calibration if you can, or use Filmmaker Mode. The latter will make the TV relatively dark, but there’s usually a way to adjust it or copy its settings and then boost the brightness in a Custom mode, which is still a big improvement over default settings from the default mode.
Here is why you are correct:
- I see what you did there.
- You are always right.
reply