date-fns VS proposal-temporal

We all know the pain of working with dates in Javascript. It needs to be more explicit, has almost no method, and could not be more clunky. For example, to create the Date January 1, 2023, you have to write a new Date (2023, 0, 1), which can be confusing for beginners, and overall just not that clear. And because of these reasons, the community has made many libraries that attempt to make Date easier to work with over the past years. Like momentjs or Date-fns. But the good news is that you won't need these third-party libraries any longer. The Temporal Date API in Javascript attempts to completely replace the Date object and fix all of the issues we generally face when working with dates.

Next we're going to install any additional dependencies we need. In our case, we're just going to need date-fns which is a library that makes it trivial to work with datetimes in JavaScript.

Obligatory plug for date-fns. https://date-fns.org/

4. Date-fns

After that we use the feed library to create the feed and to convert our posts into RSS items. First we have to install the library and install date-fns as well. We need date-fns later to simplify working with dates.

date-fns - Modern JavaScript date utility library

Currently, we are showing age in the only number of days. For better readability, let's use a function from the date-fns library. To install it, run.

Create a formatter for the post dates using date-fns:

This is it...they are just buying backlinks.

"Become a bronze sponsor and get your logo marked as Bronze Sponsor on our website that has 100K/month pageviews (https://date-fns.org) with a link..."

Look forward to Temporal.

While the manipulation with dates is still painful, Intl APIs simplify at least formatting. I'm looking forward to the stable support for Temporal API.

Temporal is pretty stable these days, and will become an official JavaScript standard. It's very well thought out. I'd recommend just using the polyfill.

PSA for JS devs: There is a new Date API in development called Temporal: https://tc39.es/proposal-temporal/docs/

For more info about this feature, you can refer to the official proposal.

If you are considering switching to a (different) date library, I would suggest to hold off. ECMAScript is about to introduce a native date and time API that is much better than the current Date functionality. It may also make the need for a third-party date library obsolete (as long as you do not need to parse custom date formats).

- https://github.com/tc39/proposal-temporal

- https://github.com/tc39/proposal-temporal#polyfills

- https://tc39.es/proposal-temporal/

- https://tc39.es/proposal-temporal/docs/index.html

- https://github.com/tc39/proposal-temporal/issues/1450

- https://tc39.es/proposal-temporal/docs/parse-draft.html

As far as I know, issue #1450 is the last remaining blocker for the standardization. I'd assume that this will be resolved in the next months. So Temporal will likely be officially released with ECMAScript 2023, but browser vendors and other implementors will start shipping it before the offical release.

Updates here https://github.com/tc39/proposal-temporal/issues/1450

This assumes two things though, and this is another point I just realized about WASM that I like, which is for (most) modern browsers asm.js / WASM doesn't have to be polyfilled, therefore with Temporal we have to consider the following:

1. Browser support - its not there yet. you'd have to polyfill. A production level polyfill is 16 KB, and is still very nasacent, and, on top of that, requires support also for BigInt[0]. The polyfill that tc39 put out is decidedly marked as non-production ready[1].

2. Polyfilling - as mentioned above, we have to deal with polyfilling the API, and that isn't a clear and easy story yet. WASM support goes back farther than this.

3. Size - its entirely possible to get WASM builds under 16 KB, and the support is better, espcially for operations on strings and numbers (dates fit this category well). The only complication I haven't quite solved yet is:

A) Can I validate that a WASM build will be under 16 KB. This is crucial. I'd even accept it at 20 KB because of wider browser support[2]

B) Can I fall back to asm.js if needed (there is a slim range of browsers that support ASM.js but not WASM, mostly pre-chromium Edge[3]

C) Is it performant compared to something like Luxon or date-fns? WASM excels at string / numerical operations so my sneaking suspicion is yes, at least in terms of the WASM operations. The complexity will be serializing the operations to a JS Date instance, Luxon & the Intl API might be most useful here

[0]: https://github.com/fullcalendar/temporal/blob/main/packages/...

[1]: https://github.com/tc39/proposal-temporal#polyfills

[2]: https://caniuse.com/wasm

[3]: https://caniuse.com/asmjs

Today I was about to write the 1st line of date/time related line for the UI of a side-project I am working. After a quick search on how to format a date, I quickly remembered how bad JavaScript dates are. So, I researched for a better solution, and came across "temporal proposal" which, while still in stage 3, seems really promising.

Luckily, that's getting fixed with Temporal (currently a stage 3 proposal). The weeks are supposed to be 1-indexed, starting with Monday. So, for example, Temporal.PlainDate.from("2022-07-03").dayOfWeek should return 7 (Sunday).