Earlier quoted context omitted.
What you want there is to stop saying "day" and instead say "24 hours." This way the code is correct and you don't need to deal with time weirdness.
You seem to assume that a day always has 24 hours. Common (but not only) non-24h day lengths are: - 23 hours - 25 hours - 24 hours 1 second - 23 hours 59 minutes 59 seconds You could assume that a day isn't exactly 24 hours, but it's close-ish to 24 hours. Nope, not even close. And that assumes that we can treat an hour as a precise measure of time (we can't). On some systems, even a second is not a precise measure o…
Temporal: The 9-year journey to fix time in JavaScript
251–260 of 284 posts
Re: Temporal: The 9-year journey to fix time in JavaScript
#252Earlier quoted context omitted.
> There wouldn't be Chrome-only sites and tools if Safari wasn't holding the web back (no "quotes" needed, as that's precisely what they're doing). It's a matter of perspective. The safer perspective is: Safari isn't holding the web back, Chrome is moving too fast. Developers making Chrome-only sites and tools are moving too fast for the safety of web standards/web platform. Where one of the safety factors is "widely…
As the links I shared showed in tremendous detail, everything you've said is complete nonsense.
I was just thinking about this this week because I have a webpage I built with offline capabilities and an excuse coming up where many of the webpage's users will be offline for a week but might have use for the webpage, but I can't easily turn it into a PWA because it was built as an MPA and there's no great high level tools for writing an MPA's ServiceWorker because most of the high level libraries are so (overly) focused on SPAs. I wish I could just put a manifest.json or some sort of zip archive users could download and have it share Local Storage.
I do pin a lot of this on Google engineers. The side effect is Safari is having a hard time implementing these "standards", but the real cause is the "standards" are over-complicated trash that are also hard to develop for. Everyone including the links you sent can see how Apple's App Store moat gives them an incentive to drag their feet on implementing these "standards" and yet no one is giving Google enough gruff for the conflict of interest with Google Play's moats and making over-complicated standards that are hard for anyone to use and harder for anyone else to implement is just another way to drag your feet and keep the whole web platform behind, without looking like you are dragging your feet.
It would feel different, too, if the fully declarative manifest.json approach hadn't briefly worked (well) in Edge (Spartan) and Firefox before Google derailed that standards train with "Chrome-first" ServiceWorker complications. Always seemed like one of the reasons that Microsoft just gave up on the web platform because they couldn't keep up with Google's machinations (and conflicts of interest) in Chrome.
Re: Temporal: The 9-year journey to fix time in JavaScript
#253Earlier quoted context omitted.
Agreed. We've almost eradicated our usage of JS Date - fixing plenty of bugs along the way, and then I extracted thousands of lines of conversions and formatting from our production app (scheduling focused) into a temporal-fun package to make it Temporal more ergonomic for lots of common cases. npmjs.com/package/temporal-fun
Word of warning Temporal relies on the Intl API for formatting, and support in Chrome is very limited due to their binary size constraints. As a result, you'll need to polyfill unsupported languages using format.js
Is there any way to force it to only use (and bundle) the polyfills that are needed assuming 2025+ era browsers?
Re: Temporal: The 9-year journey to fix time in JavaScript
#254Earlier quoted context omitted.
As the links I shared showed in tremendous detail, everything you've said is complete nonsense.
The only well supported and consistent argument I see in those links is that Safari is bad at PWAs. I agree with that. But (timely rant incoming) I also think everyone is currently bad at PWAs. The current ServiceWorker-based approach is brittle and hard to use because it is too low level and too tightly coupled to what seem to be Chrome-specific concerns. The previous manifest.json approach should have never been di…
The safari feet dragging/obstruction goes far beyond PWAs. The chart on this page is one of many examples showing how consistently far behind Safari is - they've been enormously behind chrome and firefox in coverage of tests for 7+ years. https://wpt.fyi/. And here's an extremely comprehensive article on the topic https://webventures.rejh.nl/blog/2024/history-of-safari-show...
As for standards, here's another detailed series to learn from https://infrequently.org/series/effective-standards-work/. Once again, you have it all backwards. Saying "no one is giving Google enough gruff for the conflict of interest with Google Play's moats and making over-complicated standards" is not only laughable, but just dumb - Google doesn't and, in fact, can't "make standards". Standards are something that comes about through the painful diplomatic process described in those links.
Moreover, it is quite clearly an institutional decision to hold back the web, or else they would allow for other browser engines to run on iOS rather than focing them all to be skins on webkit. Again, this is all documented in extreme detail in the articles on that site. If you find it to be still somehow lacking, the author is very open to discussion on bluesky or mastodon (I'd prepare far better though, because what you've said thus far would get eviscerated).
Also bizarre that you are saying that Google Play is somehow at the root of this supposed scheme to make web standards impossible for others to implement. Android is similarly against the web flourishing, but evidently not nearly as powerful in the greater Google enterprise as iphone/app store is in Apple.
As for MPA PWAs, there's nothing at all stopping you from serving pages from a service worker. There's plenty of valid and accessible ways to precache all the pages that a user might need while offline. Workbox (from Google!) makes it easy, but its also easy to hand-roll.
And, Microsoft most definitely has not given up on the web platform - they literally adopted and make contributions to chromium. The author of that site literally works at Microsoft now, coaching both internal and external teams on improving their use of the web, as well as contributing to standards.
I dont see any point in continuing this discussion, as you haven't shown even the slightest interest in considering how you're living in some bizarro world.
If you are actually attempting to communicate in good faith, i can't recommend strongly enough that you read that entire site. And, likewise, read and support the work of Open Web Advocacy. https://open-web-advocacy.org/
Re: Temporal: The 9-year journey to fix time in JavaScript
#255Doesn't the implementation being in rust for many browser (`temporal_rs`) make it possibly slower than it could be in pure JS? Calendar is not very intensive process, so I would not be surprised if the slowness of boundary passing make it slower.
Re: Temporal: The 9-year journey to fix time in JavaScript
#256I'm very happy about this. The fact that Temporal forces you to actually deal with the inherent complexities of time management (primarily the distinction between an instant and a calendar datetime) makes it incredibly difficult to make the mistakes that Date almost seems designed to cause. It's a bit more verbose, but I'll take writing a handful of extra characters over being called at 3AM to fix a DST related bug a…
In this day and age when a natural language query can produce the most AbstractBeanFactoryFactoryBeanFactory boilerplate at the same rate as a much more concise equivalent, does verbosity matter as much?
Re: Temporal: The 9-year journey to fix time in JavaScript
#257Earlier quoted context omitted.
You seem to assume that a day always has 24 hours. Common (but not only) non-24h day lengths are: - 23 hours - 25 hours - 24 hours 1 second - 23 hours 59 minutes 59 seconds You could assume that a day isn't exactly 24 hours, but it's close-ish to 24 hours. Nope, not even close. And that assumes that we can treat an hour as a precise measure of time (we can't). On some systems, even a second is not a precise measure o…
I am saying that you shouldn't use day as a unit of time. You should use second, minute, hour, etc, because these have a constant duration. sleep(86400) should reliably make your thread sleep for at least 24 hours.
There’s no single time unit that works for all situations.
Re: Temporal: The 9-year journey to fix time in JavaScript
#258Earlier quoted context omitted.
So it's intentional to make people pass down raw strings versus making the communication safe(er) by default?
There are no date, time or datetime types in JSON, so you'll have to serialise it to a string or an int anyway, and then when deserialising you'll need to identify explicitly which values should be parsed as dates.
Re: Temporal: The 9-year journey to fix time in JavaScript
#259I didn't know about https://docs.rs/temporal_rs/latest/temporal_rs/ I wonder if it has a chance to replace chrono and jiff in the rust ecosystem.
That being said, the library is designed to be specification conformant and with EcmaScript implementations in mind. There are some specific API choices made specifically for those clients.
That being said, we are always looking for feedback regarding the native Rust API. So feel free to try temporal_rs out and provide whatever feedback you'd like :)
Re: Temporal: The 9-year journey to fix time in JavaScript
#260> have to agree on what "now" means, even when governments change DST rules with very little notice. I didn't spot how Temporal fixes this. What happens when "now" changes? Does the library get updated and pushed out rapidly via browsers?
Right, browsers own it instead of websites needing to rebuild Moment.js bundles. Additionally, most browsers pass the ownership further to the user's OS as the IANA timezone database is a useful system-level service and best updated at the cadence of OS "required" updates.