Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Day.js – Fast 2kB alternative to Moment.js with the same modern API

day.js.org

Post reply on HN
Print view View original

121–130 of 141 posts

Re: Day.js – Fast 2kB alternative to Moment.js with the same modern API

#121

Post by michaelcampbell »

iainmerrick wrote: post #61
FrontAid wrote: post #59

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-tempor…

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?

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."

Re: Day.js – Fast 2kB alternative to Moment.js with the same modern API

#122

Post by erikpukinskis »

Day.js seems cool, but when I was evaluating these libraries I noticed the ‘startOf’ function doesn’t take a time zone argument… I guess it just presumes you want the system offset?

https://day.js.org/docs/en/manipulate/start-of

I can’t trust a date/time library that’s blasé about time zones at the API level. Undefined behavior around time zones causes a steady stream of off-by-one bugs in your codebase if you’re not vigilant.

Re: Day.js – Fast 2kB alternative to Moment.js with the same modern API

#123

Post by logifail »

joenot443 wrote: post #118
chii wrote: post #104

Earlier quoted context omitted.

> 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.

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.

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!

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.

Re: Day.js – Fast 2kB alternative to Moment.js with the same modern API

#124

Post by wefarrell »

joenot443 wrote: post #118
chii wrote: post #104

Earlier quoted context omitted.

> 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.

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.

Moment’s website suggests using other more modern alternatives so probably not a good idea to use it on a new project.

Re: Day.js – Fast 2kB alternative to Moment.js with the same modern API

#125

Post by kristopolous »

robertlagrant wrote: post #83
kristopolous wrote: post #48

Earlier quoted context omitted.

Intentionally unspecified. This isn't a personal attack but instead a systemic and cultural critique It's been like this for decades. Emotional salience sells software better than hard practicality to just about everyone. Then people rationalize their irrational choices then the timeline slips and the product sucks. You can just sit and watch it play out like someone studying monkeys. It's remarkably predicable.

How accurate can your critique be if you're so inaccurate in your metaphor for the library authors?

I'm not a primatologist.

Tell me if you've ever had this experience.

You see something that looks like it's pretty popular. You try it. You find it has nothing but problems. After much research you then find out that other people don't have the level of sophisticated asks for the product and they are doing less complicated and less critical things.

It's the disconnect between the hype and the reality that really rubs me the wrong way. I've personally lost so much time on inappropriate tools.

Again I'm not here to insult anybody specifically or to speak poorly upon any specific product. I know how many people read these comments and I don't want to cast shade on anybody's hard work. I just wish there was more authenticity to the fit and purpose of things.

I know a lot of this depends on the users. I speak as somebody who has very popular projects and very not so popular projects. The popular ones are hyped (but sarcastically) and the ones that I worked very hard on to be extremely technical about do quite poorly.

To make things super current I haven't working for about a month on an article and I have been making sure it is extremely accurate and I know that that will probably hurt me because the liberties which inherently contain inaccuracy are simply more entertaining

This is a shared experience except for a select few. This carries is over to other things. Inaccurate pop science is read much more widely then the direct research material. There's something more emotionally approachable through this tactic. It just hurts productivity and it's a shame

Re: Day.js – Fast 2kB alternative to Moment.js with the same modern API

#126

Post by 9wzYQbTYsAIc »

kristopolous wrote: post #115
9wzYQbTYsAIc wrote: post #49

Earlier quoted context omitted.

Must be a euphemism for “300 contributors on a js.org supported GitHub project”.

Immediate hostility and belittling attacks strike again. That was a reply to a comment, not to the code posted. You're being sloppy imprecise and presumptive and expressing it as haughty snide arrogance. Cool attitude

You are succumbing to the fundamental attribution error.

You described your comment being an attack on modern development culture, as your use of euphemism, you chose the insultingly denotative word “kid” to attack the project.

Cool attitude, too?

Re: Day.js – Fast 2kB alternative to Moment.js with the same modern API

#127

Post by 9wzYQbTYsAIc »

kristopolous wrote: post #125
robertlagrant wrote: post #83

Earlier quoted context omitted.

How accurate can your critique be if you're so inaccurate in your metaphor for the library authors?

I'm not a primatologist. Tell me if you've ever had this experience. You see something that looks like it's pretty popular. You try it. You find it has nothing but problems. After much research you then find out that other people don't have the level of sophisticated asks for the product and they are doing less complicated and less critical things. It's the disconnect between the hype and the reality that really rubs…

> I think the kid who wrote the library is just better at drawing cartoon characters

Quoting your writing that is probably rubbing others the wrong way, as it certainly reads easily as being specific to “these” solutions, as you put it.

You might avoid triggering people’s negative emotions by sticking to your main point and avoiding the marginalizing.

Re: Day.js – Fast 2kB alternative to Moment.js with the same modern API

#128

Post by spankalee »

FrontAid wrote: post #59

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-tempor…

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

Re: Day.js – Fast 2kB alternative to Moment.js with the same modern API

#129

Post by brundolf »

qwertox wrote: post #119
brundolf wrote: post #112

Earlier quoted context omitted.

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.

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.

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

Re: Day.js – Fast 2kB alternative to Moment.js with the same modern API

#130

Post by Mogzol »

joenot443 wrote: post #118
chii wrote: post #104

Earlier quoted context omitted.

> 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.

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.

I wouldn't recommend anyone use moment.js if they're starting a new project. It's an unnecessarily large library, and the fact that moment objects are mutable almost always causes more issues than it solves. The only reason to use it is if you're working on software that is already using it. Otherwise use a more modern, immutable datetime library like day.js, date-fns, or luxon.
Post reply on HN