241–250 of 284 posts
Earlier quoted context omitted.
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
$ du -sh '/Applications/Google Chrome.app' 1.3G /Applications/Google Chrome.app
Earlier quoted context omitted.
Technically, you're not likely to to have to fix a DST bug at 3AM any day but Sunday.
Some countries alter their observance of DST in line with their observance of Ramadan, which means that the time-offset changes aligned with Ramadan. Ramadan is observed from one visual sighting of a crescent moon to the next. Cloud conditions may prevent sighting and thereby alter the official start of Ramadan for an individual location, and from time-to-time, the start of a country's change in timezone.
A big step in the right direction, but I still don't like the API, here's why: Especially in JavaScript where I often share a lot of code between the client and the server and therefore also transfer data between them, I like to strictly separate data from logic. What i mean by this is that all my data is plain JSON and no class instances or objects that have function properties, so that I can serialize/deserialize i…
This is a real pain point and I run into the same tension in systems where data crosses serialization boundaries constantly. The prototype-stripping problem you're describing with JSON.parse/stringify is a specific case of a more general issue: rich domain objects don't survive wire transfer without a reconstitution step. That said, I think the Temporal team made the right call here. Date-time logic is one of those d…
No-one seems to like this style, but I find it much simpler than converting on db read/write and passing datetime objects around.
Earlier quoted context omitted.
No, because if I want something to happen everyday at 12 o'clock, I have to wait for one day, if I wait for 24 hours, I will be off by an hour for half of the year.
Only if you live in one of the brain dead countries that observe the dst anachronism.
our personal convictions don't change that fact.
> Whilst Firefox was able to implement Temporal as it was being specced - thanks to the great work of André Bargull (known online as Anba) It's worth highlighting that André is actually a volunteer contributor who managed to implement the whole thing by themselves.
Considering how prolific anba is, the only way we know he isn't an LLM is because he'd have to be several generations more advanced than the current SOTA. (It is possible that he might be an LLM from a few decades in the future, considering the connection to Temporal.) anba implemented all of Temporal single-handedly, plus fixed up numerous places in the spec, plus migrated the implementation over some massive change…
> 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?
Earlier quoted context omitted.
> Right now the world needs a lot more Safari and Firefox users complaining about Chrome-only sites and tools than it does people complaining about Safari "holding the web back". 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). > Safari's problems are temporary. What are you talking about? They've been woefully behind for…
> There wouldn't be Chrome-only sites and tools if Safari wasn't holding the web back Given the number of chrome-only sites that block firefox and not safari i think there are other issues in front end land
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.
No, because if I want something to happen everyday at 12 o'clock, I have to wait for one day, if I wait for 24 hours, I will be off by an hour for half of the year.
What I keep thinking about with Temporal is the adoption timeline question isn't really 'is it specced?' anymore, it's 'what minimum runtime version do I need?' Node.js, Deno, Bun all need to ship it stably, and then the practical floor for usage is wherever most prod environments are. The polyfill situation (@js-temporal/polyfill and others) doesn't really collapse until that happens.
So the speccing is done but I think we're still a couple of LTS cycles away from it being genuinely boring to reach for Temporal.