> I could see a project using use..as statements and/or aliases in config/app.php (edit: in Laravel) to import CarbonImmutable and Carbon as aliases This wouldn't work the way you're hoping for. use statements are file-scoped; a use statement in config/app.php would only affect that configuration file, not the entire application.
Oh I was thinking of adding the custom CRBN or Carb or whatever as class aliases to the original CarbonImmutable class in config/app.php. I actually haven't used aliases yet though, so I'm going by the assumption that they "just work". I've had problems in other projects too where I wanted to disallow use of classes like Carbon after declaring a child class that overrides certain behaviors, so that the code is more f…
Honestly, the best way of going about this would probably be a static analysis rule. Enforcing "use CarbonImmutable, not Carbon" doesn't need to happen at runtime.
Anyone knows how the data about each timezone stays updated within Temporal? Does the TC39 update the data somewhere, then each browser copies that data internally and releases a new version of the browser? If a user visits my website and this user has not updated their browser with the new data, will they see incorrect hours? For example Mexico removed DST in 2022 [1]. When using third party libraries like pytz or m…
Reading the proposal page “ Time Zones and Resolving Ambiguity”[1], it only mentions that it uses the IANA time zone database[2] not when it updates it. However I imagine the users computer has access to this database as well and probably handles it being updated. I’m not sure about this. It’s also entirely possible for the browser to download this database and maintain it too, separately from updates. I’m sure it de…
Yes, the user's operating system probably already has an IANA database somewhere, or the browser could bundle its own IANA database.
And the browser probably already has some way to access that database anyway.
Really, can you give a more specific example? I have never had a node upgrade break my code, and would be fairly surprised if I were to run into that situation! I also don't quite understand your other points - runtime environments are isolated, that's the point of the node_modules folder, and it's one of the things that Node/NPM does particularly well at. Were you installing your packages globally?
You must be lucky. Anything the relies on their floating ABI breaks on every update (C dependencies are very common for certain tasks)
Yeah it’s pretty much this. Something simple like scss/sass breaks a little too often but that’s the easy case. When it’s a Postgres driver it gets even more interesting.
Temporal is great. I've been using it for a while in production using a polyfill [1], and it solves all issues I've encountered with the old Date() API (which is a lot). It clearly takes inspiration from other high-quality time libraries such as chrono in Rust and Joda Time in Java and combines them into a nice API that's pretty comfortable to use. Yes, it is a bit more complex to handle since it separates time into…
> Otherwise you'll get a bug twice per year due to DST Those of us of a certain age learned long ago never to schedule cron (etc.) jobs in a production environment between 01:00 and 03:00 local time.
A long while ago my friend and I released a Safari extension that shows a few clocks in the timezones that you choose. I can't recall the details, but we had an off by 1 error on a few zones during DST.
I ended up fixing it by hand changing the time, releasing a version every 6 months for years, otherwise we would get mails about it from the few users using it.
I think I could automate this or otherwise solve the issue, but it always felt nice to move the clocks of a few hundred people.
I work with both node and Python. The difference in upgrade experiences is measured in several orders of magnitude. My most recent few projects jumped Python versions because features I wanted were introduced. I cannot remember a time I had to rewrite application code because of an upgraded Python version (well I do, it was the Python 2 to 3 migration a very long time ago). In the meantime new node versions constantl…
Really, can you give a more specific example? I have never had a node upgrade break my code, and would be fairly surprised if I were to run into that situation! I also don't quite understand your other points - runtime environments are isolated, that's the point of the node_modules folder, and it's one of the things that Node/NPM does particularly well at. Were you installing your packages globally?
See my other comment but also npm is installed globally and global packages are available so there is no isolation. Compare to Python where a virtual env is complete with a separate copy of the Python interpreter, associated tools (pip, etc.), and only local packages are available. And best of all, you can call binaries inside the virtual env from outside it as normal executables and it just works. No need to mess with $PATH or set any other env variables, just call ./venv/bin/foobar and foobar will run in the context of that venv. Recreating this on a different machine is amazingly simple if you can use one of the already available Python binaries on that system, and trivial if not (compiling Python takes a few minutes and there are lots of tools that will make that process even simpler than the two commands you need to do it). People talk about Docker being the universal environment to run things but Python development doesn’t even need that 99% of the time. And the standard library is chock full of sane, performant modules that allow you to do everything you need, from asyncio to parsing arcane binary formats. My installed packages typically number in dozens, not thousands like JS, because the standard library provides so much already.
Cannot wait. That said, somehow I don't think it will help us with a UK-based API provider we work with that provide us with ISO-encoded UTC time strings that are actually BST during northern hemisphere summer (or localised strings, e.g. +6 where the datetime component is actually UTC).
Man, that took some time to find in the docs: Temporal.ZonedDateTime.prototype.withTimeZone() [0], which allows to convert from one timezone to another const meetingTime = Temporal.ZonedDateTime.from( "2021-08-01T12:00[America/New_York]", ); const meetingTimeInParis = meetingTime.withTimeZone("Europe/Paris"); console.log(meetingTimeInParis.toString()); // 2021-08-01T18:00:00+02:00[Europe/Paris] To me, timezone transl…
The DurationFormatter proposal allows you control over which units you want formatted and at what brevity: eg. 1 yr, 3 hours, and 3m. See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... I partially implemented it in the icu4x library.
DurationFormat looks cool but it didn’t behave as I expected.
Related. Others? JavaScript Temporal Is Coming - https://news.ycombinator.com/item?id=42809834 - Jan 2025 (18 comments) Mozilla: Temporal (Limited Availability) - https://news.ycombinator.com/item?id=42776548 - Jan 2025 (1 comment) Is It Time for the JavaScript Temporal API? - https://news.ycombinator.com/item?id=29712118 - Dec 2021 (100 comments) Temporal: Getting started with JavaScript's new date time API - https:…
I appreciate how truly awesome the Web APIs are nowadays but I still feel sad that the first submission for this was almost 4 years ago in March 2021.
Does this mean we can finally stop downloading and running a third of a MB of js on every website? moment.js, luxon, date-fns, are all obsolete? https://bundlephobia.com/package/moment@2.30.1
moment.js has been obsolete for years. I've considered it as a sign of an unmaintained code for at least ~5 years by now.
There has been so many better and lightweight alternatives for years that if you haven't already refactored it away, you just don't care about your users or the bundle size. (And I have personally done that exercise a handful of times myself, I know it can be painful, but it's just one relatively small PR!)