Our great sponsors
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
In JavaScript you actually use `Intl.DateTimeFormat`[1] to format datetimes, which takes in a pretty descriptive configuration object with keys such as `month: "short"`, `hour: "2-digit"`, and `hour12: true`.
This is missing in the OP explainer, so I created a PR[2].
1: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
2: https://github.com/you-dont-need/You-Dont-Need-Momentjs/pull...
Shameless plug: if you’re looking for natural language date parsing, check out Sherlock.js - https://github.com/neilgupta/Sherlock
> I doubt browsers are smart enough to bulk fetch multiple unpkg dependencies in one request.
https://github.com/WICG/import-maps/issues/209
Yep! Most examples in the Rust cookbook[0] uses chrono[1].
But note that before Chrono there were other time libraries; one of them was called time[2] - IIRC it was created from code removed from Rust's stdlib std::time[3]. It eventually proved to be the best decision: designing a good API is a hard effort, and any design was prone to have mistakes and warts.
Chrono provides interoperability with both std::time and the time crate. It acknowledges other datetime crates that it was inspired, like datetime-rs[3] which itself was inspired by Joda time.
[0] https://rust-lang-nursery.github.io/rust-cookbook/datetime.h...
[1] https://crates.io/crates/chrono
[2] https://crates.io/crates/time
[3] https://github.com/depp/datetime-rs
How come the js-joda library is never mentioned in discussions about javascript date/time libraries? its API is perfect and it has been around forever. but instead the community seems to keep inventing more and more new datetime libraries. i don't understand why js-joda seems to be ignored
https://js-joda.github.io/js-joda/
Yep, indeed there are ways to migrate, but it's not necessarily easy. For instance in my last project, we used moment-timezone, and integrated other libraries such as https://github.com/urish/ngx-moment to format date/times in component templates. Of course it's possible to move away from that, but it would take time away from more useful work.
the breakdown is not complete, for example I needed to pull in a new library to get the localized first day of the week with Luxon (this differs based on locale)
Also I really don't recommend dayJS, its documentation is crap (for example this is the documentation of its timezone plugin: https://day.js.org/docs/en/plugin/timezone ) and is full of serious bugs that its developer does not respond to: https://github.com/iamkun/dayjs/issues
Also the code style is really concerning too: https://github.com/iamkun/dayjs/issues/1598
I've build a library to do that (based on various known techniques) in [1]; it's also combined with validation based on zod. I would say it's usable but of course having true nominal type support in TypeScript would be way better.
[1]: https://github.com/renke/vo/tree/master/packages/vod
Yes, it's always been possible to get some kind of string from datetimes, but I specifically care about specifying what string, same with parsing. "Just use a locale's default" might work if you're making a web app for clients who aren't picky, but using JS as a "serious" language it's a really big hole. There's plenty of formats that demand non-ISO date formats and I currently need to use a third-party library. I've gotten used to than in JS, but I was hoping a new take on dates will sort this out. Oh well, I'll have to just hope it makes it to v2: https://github.com/js-temporal/proposal-temporal-v2.