Add support for js-joda about date-io HOT 16 CLOSED

Our team's main reason to choose js-joda over any of the alternatives:

• Domain driven representation of different concepts like Instant, LocalDateTime or ZonedDateTime rather than wrapping/patching a jack-of-all-trades type like JavaScript's date type.

I think it should not be a problem to add this to the main repo

I'd love to hear that date-io is officially supporting js-joda!

from date-io.

I'm also interested in support for js-joda integration and would like to see this issue reopened.

My usecase: Kotlin's officially supported multiplatform datetime library kotlinx-datetime uses js-joda in the JS side; kotlinx-datetime allows us to have a single representation of dates in multiple platforms when writing Kotlin code (server/JVM, Android, web/JS, etc).

Since our web frontend integrates with Kotlin-compiled JS code which is already using js-joda, it would make little sense to introduce a second date library.

from date-io.

I think we should not recommend it for users :)

from date-io.

Isn't the whole point of this library to make it easier for people to choose? I'll have to check what size is left in my app after tree shaking.

from date-io.

@grantsru Please checkout this fork https://github.com/prinzdezibel/date-io (supports only v1.3.13 of @date-io/core for now)

from date-io.

@dmtrKovalenko https://bundlephobia.com/package/@js-joda/[email protected] is half the size of https://bundlephobia.com/package/[email protected]
It is also extremely stable the root of the api has not changed since 2014.
I am not saying moment is the exemplar. The nice part about joda-time is that the distinct type LocalDate vs ZonedDate and LocalDateTime vs ZonedLocalDateTime really help my devs avoid muddled thinking about dates, timezones and time. I just made a new pull request #589 It is a bit more abstract than previous attempts everything is hung off the abstract type Temporal. If you want I can get it up to 100 % coverage. I would take responsibility for its maintenance. If you still are not interested I would like to investigate another repository outside the monorepo, but maybe privilege to release to @date-io/js-joda .
Thanks for your work in maintaining this library.

from date-io.

43 kb?!!!

from date-io.

Yeah, but the cost of supporting this library in official monorepo will be much incompatible with users, that are using this lib.

It is still possible to make your own adapter. Just implement interface and publish npm package.

from date-io.

For all people who need it nonetheless please head over to: https://github.com/prinzdezibel/date-io

@dmtrKovalenko: May I ask you to reconsider your decision? Oftentimes one is not in the position to choose the date utility library used for a given project. Those people may have no choice but to stick with js-joda. Besides from that js-joda seems to be a very complete and mature library with "localization" batteries included. This may well justify its somewhat bigger size.

I would be very happy to file a PR if you change your mind, @dmtrKovalenko.

from date-io.

My main thoughts:

1. this is not so popular library (https://www.npmtrends.com/@js-joda/core-vs-date-fns-vs-moment)
2. So giant bundlesize https://bundlephobia.com/result?p=@js-joda/[email protected]
3. Too often breaking changes releases

I am not really against of supporting a lot and a lot of libraries, but each new library makes support of @date-io harder and harder. If there is a reasonable answer why you are choosing js-joda instead of other libs, I think it should not be a problem to add this to the main repo

Anyway we add a link to your npm library and GitHub repo with support of js-joda from the official documentation

from date-io.

I also heavily use js-joda and would like to see date-io supporting it.

from date-io.

@prinzdezibel if you could extract and publish your date-io package separately from fork - I would love to add a link to the README

from date-io.

@dmtrKovalenko What are your thoughts on supporting it officially in your project? (provided that my work is compatible with v2, of course)

from date-io.

@dspiteself sorry for not answering I was sure that I responded, I am totally OK for supporting js-joda, so if you can get PR up to 100% coverage – I`ll merge and publish it

from date-io.

One more interesting thing with js-joda is that JavaScript Temporal #466 is very close to js-joda mainly some renames and a few changes to JavaScript idiom.

from date-io.

Our team's main reason to choose js-joda over any of the alternatives:

• Domain driven representation of different concepts like Instant, LocalDateTime or ZonedDateTime rather than wrapping/patching a jack-of-all-trades type like JavaScript's date type.

In our team's case (decision predates my involvement):

• alignment to use of, and experience with, Joda in an associated Java codebase

from date-io.