6 ms·

Please pardon this drive-by assessment of JS calendar libraries by a casual user. moment.js: Mutable. Thank you, next. Luxon: Takes the effort to implement `I

by dmit 6y ago

Please pardon this drive-by assessment of JS calendar libraries by a casual user. moment.js: Mutable. Thank you, next. Luxon: Takes the effort to implement `Interval`, which would be `Range<DateTime>` in any proper language, but somehow avoids providing separate `Date` and `Time` objects. Day.js: When you kinda like moment.js, but your bundler says it's too fat. date-fns: The finest of pure, curry-able functions over the minefield that is Javascript's `Date` object. js-joda: If Javascript didn't have classes already, this project would probably port the entire Java runtime to JS just to replicate them. Likely the most correct handling of date/time stuff available for the browser, but damn, at what cost? ------------ Edit: this turned out way too negative, my bad. All I wanted was a library that offered: 0) Type definitions. 1) Immutable classes of `Date` (year, month, day), `Time` (hour, minute, etc), `DateTime` (the prior two combined), `Instant` (for a certain moment on the global timeline), and `Duration`. 1b) `DateTime` should probably be split into two separate things, one of which is aware of time zones. 2) All the obvious date arithmetic functions - duration between dates, adding/subtracting durations, etc etc.

glintik 6y ago
"moment.js: Mutable. Thank you, next." Mutable is not bad, buddy. You live in mutable world.
- theon144 6y ago
  Mutable is not bad when necessary, but otherwise I'd say that immutable is generally quite good.
- japgolly 6y ago
  False comparison. We're not creating a copy of the mutable world, we're writing software. Pretty different. Good luck programming in DNA or whatever and knowing that your code does what you want it to do.
- deleted 6y ago
  [deleted]
- TheCoelacanth 6y ago
  No I don't. I live in an immutable, four-dimensional world /s These are all just models of the real world, not the reality. The real world can be modeled equally accurately as mutable or immutable, it just depends which properties of the real world you care about modeling.
- bbotond 6y ago
  Mutability, in this case, can be pretty unexpected. Just like you don't expect the expression a + 5 to change the value of a but to return a new number, most people don't expect myDate.add(5, 'days') to change the value of myDate. I know that moment values are mutable, yet I often forget it while writing code and make dangerous mistakes because of how unnatural it is to see an arithmetic expression that is not immutable.
  - mywittyname 6y ago
    That's totally expected behavior to me. I would expect to use something like Moment.addDate(date1, 5, 'days') if I wanted a new instance of a date to be returned. Even in javascript-land, methods like that will have side-effects, yet still return this often just for the sake of method chaining. E.g. date.add(5, 'days).format("%Y-%m-%d") would mutate date, but return the same instance as a convenience.
RobertKerans 6y ago
> `DateTime` should probably be split... https://github.com/tc39/proposal-temporal https://github.com/tc39/proposal-temporal
3np 6y ago
Anyone has an idea for a solid module that supports representations of sub-millisecond precision (preferrably ns but at least us)?
jeroenhd 6y ago
Can you explain why you find mutability to be a showstopper? Is this a front end developer thing? I like my consts and all where relevant, but I don't see why mutability is such a problem. Javascript is an imperative language where almost everything more complicated than a number is mutable. I see the lack of creating copies of objects with every operation as a benefit because of the RAM and CPU cycles it saves. Is it because the API returns a reference to an object as well as updating said object? That's the API I'd expect, personally; if I want to do an addition of 1 to i, I'd write i += 1 and expect i to have incremented. I don't see why moment.add() should behave differently?
- turdnagel 6y ago
  Basically, unexpected behavior. One of the "footguns" is that it's easy to write to a Moment object when you mean to be reading from it. And by the way, you can mutate objects declared with `const` in JS - you just can't reassign them.
  - holtalanm 6y ago
    I don't view the mutability of moment as a complete show stopper, though. If you limit the surface area of the mutability by hiding the underlying moment object within an abstraction, then you can at the very least keep the chances of misusing moment to a minimum.
    - turdnagel 6y ago
      I also think it's not a showstopper for Node.js apps. For bundling in a front-end app it's waaaay too big.
      - hajile 6y ago
        The moment locales webpack plugin goes a very long way toward dealing with the size downside of the library. That said, we wouldn't be in this position if more companies used a shared CDN for libraries instead of always bundling them.
mj1586 6y ago
Hi. You seem to be asking for Temporal. It's coming, we hope! https://tc39.es/proposal-temporal/docs/index.html https://tc39.es/proposal-temporal/docs/index.html
- dmit 6y ago
  Yes, thank you! I've seen this before and forgot. Looks like it's at Stage 2 right now, so still a ways to go until shipping, but should resolve all my gripes when it does.
jimmaswell 6y ago
> moment.js: Mutable. Thank you, next. A petty, thoughtless dismissal that reflects more on the one saying it than the library.
cwmma 6y ago
> 1b) `DateTime` should probably be split into two separate things, one of which is aware of time zones. due to daylight saving timezones depend on the date, which makes it hard to separate date and time
- dmit 6y ago
  You're right! I should have phrased that better. I didn't mean splitting `DateTime` into timezone-aware `Date` and `Time`. I meant two different `DateTime`s. Sometimes you need "Wake me up on December 24th at 10:00, regardless of where I am that day", and sometimes you want "The match will start on May 1st at 21:00 British Standard Time, and I want to be alerted about this even if I'm in New Zealand at that moment." What I meant is a distinction between a `LocalDateTime` (first example, timezone is not relevant) and a `ZonedDateTime` (second example). The latter is very close to `Instant`, which is a point on the UTC timescale, but the subtle difference is that if timezone definitions were to change - as they often do - the `ZonedDateTime` would correctly remap to the actual `Instant` when the event was happening.

by dmit 6y ago

glintik 6y ago

"moment.js: Mutable. Thank you, next." Mutable is not bad, buddy. You live in mutable world.

theon144 6y ago
Mutable is not bad when necessary, but otherwise I'd say that immutable is generally quite good.
japgolly 6y ago
False comparison. We're not creating a copy of the mutable world, we're writing software. Pretty different. Good luck programming in DNA or whatever and knowing that your code does what you want it to do.
deleted 6y ago
[deleted]
TheCoelacanth 6y ago
No I don't. I live in an immutable, four-dimensional world /s These are all just models of the real world, not the reality. The real world can be modeled equally accurately as mutable or immutable, it just depends which properties of the real world you care about modeling.
bbotond 6y ago
Mutability, in this case, can be pretty unexpected. Just like you don't expect the expression a + 5 to change the value of a but to return a new number, most people don't expect myDate.add(5, 'days') to change the value of myDate. I know that moment values are mutable, yet I often forget it while writing code and make dangerous mistakes because of how unnatural it is to see an arithmetic expression that is not immutable.
- mywittyname 6y ago
  That's totally expected behavior to me. I would expect to use something like Moment.addDate(date1, 5, 'days') if I wanted a new instance of a date to be returned. Even in javascript-land, methods like that will have side-effects, yet still return this often just for the sake of method chaining. E.g. date.add(5, 'days).format("%Y-%m-%d") would mutate date, but return the same instance as a convenience.

RobertKerans 6y ago

> `DateTime` should probably be split... https://github.com/tc39/proposal-temporal https://github.com/tc39/proposal-temporal

3np 6y ago

Anyone has an idea for a solid module that supports representations of sub-millisecond precision (preferrably ns but at least us)?

jeroenhd 6y ago

Can you explain why you find mutability to be a showstopper? Is this a front end developer thing? I like my consts and all where relevant, but I don't see why mutability is such a problem. Javascript is an imperative language where almost everything more complicated than a number is mutable. I see the lack of creating copies of objects with every operation as a benefit because of the RAM and CPU cycles it saves. Is it because the API returns a reference to an object as well as updating said object? That's the API I'd expect, personally; if I want to do an addition of 1 to i, I'd write i += 1 and expect i to have incremented. I don't see why moment.add() should behave differently?

turdnagel 6y ago
Basically, unexpected behavior. One of the "footguns" is that it's easy to write to a Moment object when you mean to be reading from it. And by the way, you can mutate objects declared with `const` in JS - you just can't reassign them.
- holtalanm 6y ago
  I don't view the mutability of moment as a complete show stopper, though. If you limit the surface area of the mutability by hiding the underlying moment object within an abstraction, then you can at the very least keep the chances of misusing moment to a minimum.
  - turdnagel 6y ago
    I also think it's not a showstopper for Node.js apps. For bundling in a front-end app it's waaaay too big.
    - hajile 6y ago
      The moment locales webpack plugin goes a very long way toward dealing with the size downside of the library. That said, we wouldn't be in this position if more companies used a shared CDN for libraries instead of always bundling them.

mj1586 6y ago

Hi. You seem to be asking for Temporal. It's coming, we hope! https://tc39.es/proposal-temporal/docs/index.html https://tc39.es/proposal-temporal/docs/index.html

dmit 6y ago
Yes, thank you! I've seen this before and forgot. Looks like it's at Stage 2 right now, so still a ways to go until shipping, but should resolve all my gripes when it does.

jimmaswell 6y ago

> moment.js: Mutable. Thank you, next. A petty, thoughtless dismissal that reflects more on the one saying it than the library.

cwmma 6y ago

> 1b) `DateTime` should probably be split into two separate things, one of which is aware of time zones. due to daylight saving timezones depend on the date, which makes it hard to separate date and time

dmit 6y ago
You're right! I should have phrased that better. I didn't mean splitting `DateTime` into timezone-aware `Date` and `Time`. I meant two different `DateTime`s. Sometimes you need "Wake me up on December 24th at 10:00, regardless of where I am that day", and sometimes you want "The match will start on May 1st at 21:00 British Standard Time, and I want to be alerted about this even if I'm in New Zealand at that moment." What I meant is a distinction between a `LocalDateTime` (first example, timezone is not relevant) and a `ZonedDateTime` (second example). The latter is very close to `Instant`, which is a point on the UTC timescale, but the subtle difference is that if timezone definitions were to change - as they often do - the `ZonedDateTime` would correctly remap to the actual `Instant` when the event was happening.