6 ms·

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

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 - https://github.com/tc39/proposal-temporal#polyfills https://github.com/tc39/proposal-temporal#polyfills - https://tc39.es/proposal-temporal/ https://tc39.es/proposal-temporal/ - https://tc39.es/proposal-temporal/docs/index.html https://tc39.es/proposal-temporal/docs/index.html - https://github.com/tc39/proposal-temporal/issues/1450 https://github.com/tc39/proposal-temporal/issues/1450 - https://tc39.es/proposal-temporal/docs/parse-draft.html 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.

iainmerrick 4y ago
Instead of using something that works right now, you’re saying people should hold off for a few months, then start using a prerelease API?
- badlucklottery 4y ago
  They mentioned "switching" which implies an already working solution. Within that context, yeah, maybe wait a few months if you can afford to. Also, once the spec is finalized, there may also be a compliant polyfill available. If so, you'll get the functionality early and still have good compatibility down the line.
- dspillett 4y ago
  If you have something working, perhaps delay refactoring to a new library. Or as it is coming RealSoonNow(tm) perhaps start looking into polyfills as you are going to need one anyway for a story time at least to support LTS browser versions.
- jwalton 4y ago
  Welllll… “works right now” is perhaps an overly strong assertion when it comes to day.js. I was working on a library we use for parsing "schedules" (like, alarm turns on at 9:00pm on Thursday, and off again at 7:00am on Friday). I was doing things like computing the number of seconds until the next scheduled transition. I tried switching from moment to day.js, and my unit tests immediately failed. Within a couple of hours I’d opened two bugs [1][2], both related to incorrect behaviour in corner cases (like generating the incorrect date when near a daylight saving time transition). The fact that it only took me a few hours to find these suggests there are plenty more bugs like these to find. The fact that these bugs have been open since the start of March with no movement on them suggests they aren’t too interested in correct behaviour (or perhaps they’re just your typical under-staffed open source project). Maybe I just got super unlucky and ran into the only two bugs here… but it’s not likely. Luxon and moment.js both handled these cases perfectly. If you’re looking to move from whatever you’re using now, and you can’t wait for the new standard, I’d pick one of those. [1]: https://github.com/iamkun/dayjs/issues/1816 https://github.com/iamkun/dayjs/issues/1816 [2]: https://github.com/iamkun/dayjs/issues/1817 https://github.com/iamkun/dayjs/issues/1817
- michaelcampbell 4y ago
  A more charitable read might be, "If you're going to change to something, you might be able to wait and make 1 change rather than 2."
yilugurlu 4y ago
Having read the cookbook [1], and wow that's a complex API out there. I can see that there will be a `Temporal Light` to allow us to do `now().startOf('month')` like calls. [1] https://tc39.es/proposal-temporal/docs/cookbook.html https://tc39.es/proposal-temporal/docs/cookbook.html
- moogly 4y ago
  Wouldn't this work? const firstInMonth = Temporal.Now.with({ day: 1 });
  - chrismorgan 4y ago
    Correction: Temporal.Now.plainDateISO().with({ day: 1 }) Today (2022-10-10 on my computer), that’ll get you a PlainDate representing 2022-10-01. The “ISO” in there identifies the calendar. Want to know what the first of the current month in the Hebrew calendar is? Temporal.Now.plainDate("hebrew").with({ day: 1 }) And that gives you 2022-09-26[u-ca=hebrew].
chii 4y ago
> I would suggest to hold off you don't need to hold off - you just wrap the library in an api of your own, specific for your usage. Then, when/if the ecmascript standard library adds a good one in, you just need to re-implement the wrapper, which would be presumably pretty easy as the api surface area is fairly small.
- anamexis 4y ago
  Date libraries and small API surface areas are not usually things I associate with each other.
- joenot443 4y ago
  If I were helping someone start a web project _right now_ I'd probably tell them to just use Moment.js and forget about it. Any live web product I've ever worked on has always had more than enough to work on to keep updating the date-time library at the bottom of the to-do list almost indefinitely.
  - wefarrell 4y ago
    Moment’s website suggests using other more modern alternatives so probably not a good idea to use it on a new project.
  - logifail 4y ago
    I was tangentially involved in the back-end data part of a web project in the last few weeks. Right from the beginning, I told anyone who would listen that the underlying data was in UTC. So far, so good. They get to T-24h for the client's Big Demo Day... ...and someone in London, UK notices the front end UI times are all an hour out (that would be because the UK is still on summer time, UTC+1). I happened to be in Germany and after finally being given a login for the UI found that, wonder of wonders, the timings were two hours out! <groan> So we had to bodge the API to fiddle the times forward to UTC+1 for the purposes of the damned demo. Someone is presumably going to find this in the repo waaaay in the future and ask themselves "wtf were they thinking?". I wish I knew the answer.
  - 4y ago
brundolf 4y ago
Moment.js was one of our biggest dependencies, and the transition to Day.js was easy. I'm certainly glad we didn't hold off. I'm sure we'll switch to Temporal eventually, but it's misguided to suggest everyone should wait a year or more to improve their sites just to save a little effort in the interim.
- qwertox 4y ago
  One has also got to hope that Temporal offers all the features a well built daytime library does offer. What good is it if Temporal is lacking that one feature you need, so that you end up including another library as well. By then you can assume that the other library will be a lightweight wrapper around Temporal.
  - brundolf 4y ago
    Temporal looks fantastic from what I've seen, it's a very filled-out spec, and yeah, at the very least it should make these kinds of libraries smaller I just think it was needlessly assertive to say nobody should migrate their datetime library until it's ready
spankalee 4y ago
There's a good polyfill for Temporal here: https://github.com/js-temporal/temporal-polyfill https://github.com/js-temporal/temporal-polyfill

iainmerrick 4y ago

Instead of using something that works right now, you’re saying people should hold off for a few months, then start using a prerelease API?

badlucklottery 4y ago
They mentioned "switching" which implies an already working solution. Within that context, yeah, maybe wait a few months if you can afford to. Also, once the spec is finalized, there may also be a compliant polyfill available. If so, you'll get the functionality early and still have good compatibility down the line.
dspillett 4y ago
If you have something working, perhaps delay refactoring to a new library. Or as it is coming RealSoonNow(tm) perhaps start looking into polyfills as you are going to need one anyway for a story time at least to support LTS browser versions.
jwalton 4y ago
Welllll… “works right now” is perhaps an overly strong assertion when it comes to day.js. I was working on a library we use for parsing "schedules" (like, alarm turns on at 9:00pm on Thursday, and off again at 7:00am on Friday). I was doing things like computing the number of seconds until the next scheduled transition. I tried switching from moment to day.js, and my unit tests immediately failed. Within a couple of hours I’d opened two bugs [1][2], both related to incorrect behaviour in corner cases (like generating the incorrect date when near a daylight saving time transition). The fact that it only took me a few hours to find these suggests there are plenty more bugs like these to find. The fact that these bugs have been open since the start of March with no movement on them suggests they aren’t too interested in correct behaviour (or perhaps they’re just your typical under-staffed open source project). Maybe I just got super unlucky and ran into the only two bugs here… but it’s not likely. Luxon and moment.js both handled these cases perfectly. If you’re looking to move from whatever you’re using now, and you can’t wait for the new standard, I’d pick one of those. [1]: https://github.com/iamkun/dayjs/issues/1816 https://github.com/iamkun/dayjs/issues/1816 [2]: https://github.com/iamkun/dayjs/issues/1817 https://github.com/iamkun/dayjs/issues/1817
michaelcampbell 4y ago
A more charitable read might be, "If you're going to change to something, you might be able to wait and make 1 change rather than 2."

yilugurlu 4y ago

Having read the cookbook [1], and wow that's a complex API out there. I can see that there will be a `Temporal Light` to allow us to do `now().startOf('month')` like calls. [1] https://tc39.es/proposal-temporal/docs/cookbook.html https://tc39.es/proposal-temporal/docs/cookbook.html

moogly 4y ago
Wouldn't this work? const firstInMonth = Temporal.Now.with({ day: 1 });
- chrismorgan 4y ago
  Correction: Temporal.Now.plainDateISO().with({ day: 1 }) Today (2022-10-10 on my computer), that’ll get you a PlainDate representing 2022-10-01. The “ISO” in there identifies the calendar. Want to know what the first of the current month in the Hebrew calendar is? Temporal.Now.plainDate("hebrew").with({ day: 1 }) And that gives you 2022-09-26[u-ca=hebrew].

chii 4y ago

> I would suggest to hold off you don't need to hold off - you just wrap the library in an api of your own, specific for your usage. Then, when/if the ecmascript standard library adds a good one in, you just need to re-implement the wrapper, which would be presumably pretty easy as the api surface area is fairly small.

anamexis 4y ago
Date libraries and small API surface areas are not usually things I associate with each other.
joenot443 4y ago
If I were helping someone start a web project _right now_ I'd probably tell them to just use Moment.js and forget about it. Any live web product I've ever worked on has always had more than enough to work on to keep updating the date-time library at the bottom of the to-do list almost indefinitely.
- wefarrell 4y ago
  Moment’s website suggests using other more modern alternatives so probably not a good idea to use it on a new project.
- logifail 4y ago
  I was tangentially involved in the back-end data part of a web project in the last few weeks. Right from the beginning, I told anyone who would listen that the underlying data was in UTC. So far, so good. They get to T-24h for the client's Big Demo Day... ...and someone in London, UK notices the front end UI times are all an hour out (that would be because the UK is still on summer time, UTC+1). I happened to be in Germany and after finally being given a login for the UI found that, wonder of wonders, the timings were two hours out! <groan> So we had to bodge the API to fiddle the times forward to UTC+1 for the purposes of the damned demo. Someone is presumably going to find this in the repo waaaay in the future and ask themselves "wtf were they thinking?". I wish I knew the answer.
- 4y ago

brundolf 4y ago

Moment.js was one of our biggest dependencies, and the transition to Day.js was easy. I'm certainly glad we didn't hold off. I'm sure we'll switch to Temporal eventually, but it's misguided to suggest everyone should wait a year or more to improve their sites just to save a little effort in the interim.

qwertox 4y ago
One has also got to hope that Temporal offers all the features a well built daytime library does offer. What good is it if Temporal is lacking that one feature you need, so that you end up including another library as well. By then you can assume that the other library will be a lightweight wrapper around Temporal.
- brundolf 4y ago
  Temporal looks fantastic from what I've seen, it's a very filled-out spec, and yeah, at the very least it should make these kinds of libraries smaller I just think it was needlessly assertive to say nobody should migrate their datetime library until it's ready

spankalee 4y ago

There's a good polyfill for Temporal here: https://github.com/js-temporal/temporal-polyfill https://github.com/js-temporal/temporal-polyfill