feat(datepicker): Add additional date adapter implementations

[jelbourn]

This issue tracks creating additional date adapter implementations in addition to the existing MomentJS implementation. Libraries to consider include:

• [x] Luxon
• [x] date-fns
• [ ] Day.js

[andriyor]

Consider of using date-io

[ahmadalfy]

Voting for date-fns. Moment.js entered maintenance mode.

[ghost]

+1 @ahmadalfy go for date-fns! It's lightweight & fast.

[mtpultz]

I'm hoping by subscribing to this feature request for updates with Moment entering end of life that this doesn't mean I'm going to get a bunch of emails with everyones vote/opinion on which adapter implementation should be considered based on your own personal preference. Seems more logical to expand the list put forth by @jelbourn like @andriyor has since it wasn't included in the original list, but not voting individually through posts

[bbarry]

I am wondering if the material components repo is the right place for these things. IMO material should publish the api interface and encourage community contributions for the adapter services. Perhaps an endorsement program or something would be nice with a path to being mentioned in the documentation (a similar system could be useful for a number of projects that I've seen die stale code deaths from lack of updates because the projects fail to gain notoriety for the tiny enhancements they bring to the material ecosystem).

I'm assuming that the moment adapter exists due to use within Google. The only benefit I see to having it in this repo is to gain access to Google's robust build and package system (not always a benefit either; complexity always sucks) and maybe access to some test cases that aren't made public. If those aren't going to advantage these additional implementations then there seems little point to supporting them here (outside the notoriety angle which I think is a PR issue and not really a technical one).

[AwesomeObserver]

date-fns of course

[andriyor]

https://twitter.com/dmtrKovalenko/status/1254414963306909699?s=20

[jelbourn]

The current state of this is that we're still discussing whether this is something we want to maintain as a first-party (Angular team) thing, or instead defer to community implementations of different date adapters. We'll definitely weigh community feedback here.

[MatthiasKunnen]

@jelbourn I've once looked into creating a date-fns date adapter but decided against it because I deemed it a huge hassle to get the necessary testing framework into my own project. If there is a way the Angular team could provide some kind of base for date adapter libraries to build on I reckon third party implementations would be attainable.

[KingDarBoja]

@jelbourn I've once looked into creating a date-fns date adapter but decided against it because I deemed it a huge hassle to get the necessary testing framework into my own project. If there is a way the Angular team could provide some kind of base for date adapter libraries to build on I reckon third party implementations would be attainable.

There is some gist for a date-fns adapter, which I copied onto my project and worked like a charm, but in this case, there is already a base for building your own date adapter via https://material.angular.io/components/datepicker/overview#choosing-a-date-implementation-and-date-format-settings so not sure what you meant.

Cheers!

[MatthiasKunnen]

@KingDarBoja, making a quick implementation of a date adapter is pretty easy. Making a properly tested date adapter and keeping it in sync with changes in Angular is something else. The current MomentDateAdapter has the luxury of residing in the Angular Components source and can use the extensive testing framework that is available.

When a breaking change to the DateAdapter class is made, all third party date adapters will need to release an update to support this so you could have the problem that e.g. Angular 11 releases but your DateAdapter only supports up to Angular 10.

For testing, versioning, and breaking changes it will be easier if the code resides in this repository. That being said, maintaining a date adapter for every date library out there is not really what I believe that the Angular team should put their limited time into.

[toamitc]

Any path forward on these adapters? Need to replace moment-adapter with luxon-adapter?

[MatthiasKunnen]

My proposal is for the Angular team to create a package to test new date adapters, e.g. @angular/date-adapter-tests. The major version of this package would be kept in sync with the version of @angular/material it supports. This package would then be used by the community-made date adapters. This ensures consistency between all the date adapters and when changes to DateAdapter occur, date adapter maintainers can pull the latest @angular/date-adapter-tests and simply run the tests to verify their implementation is still correct or requires work.

Another possibility is instead of a package, the angular team could create a repository that community date adapters could fork and apply patches from.

[mtpultz]

PR for LuxonDateAdapter that has been open for over a year: https://github.com/angular/components/pull/14681#issuecomment-745170191. Finishing off this PR and merging it in would buy time for discussions, debates, opinions, etc; while not perpetuating the use of Moment in new and current projects.

[KingDarBoja]

Some community-made date-fns adapter has been done (seems based on the gist I shared before) as you can check out at https://github.com/sapozhnikovay/ngx-mat-datefns-date-adapter

[bhanna1693]

Some community-made date-fns adapter has been done (seems based on the gist I shared before) as you can check out at https://github.com/sapozhnikovay/ngx-mat-datefns-date-adapter

This project is well done IMO. But the fact remains that an organization is unlikely to accept a third party date adapter solution unless it is held to the same testing standards as the MomentDateAdapter. Any updates/eta on the progress of the @angular/date-adapter-tests idea? I really like the sound of that

[andreialecu]

Just leaving this here in case people are looking for it. I took the PR that adds Luxon in https://github.com/angular/components/pull/14681#issuecomment-745170191 and published it to NPM a while ago at:

https://www.npmjs.com/package/ngx-material-luxon

It also fixes some bugs that were present in the original PR and adds a feature to set the first day of the week. Other contributions are welcome in: https://github.com/andreialecu/ngx-material-luxon

When a decision is made to add date adapters back to @angular/* I'd be happy to contribute the fixes back, and obsolete my package.

[tuuling]

https://www.npmjs.com/package/@angular/material-date-fns-adapter looks like something is brewing, any idea when this could be actually released?

[jelbourn]

It's riding the train to v13 stable

[EusebiuDev]

Any updates on the Day.js adapter?

[JohanHeyvaert]

Great that there is finally an adapter for date-fns.

Now it would be even more great if it would offer the same features.

For the moment (no pun intended) we are missing the option to disable the automatic timezone conversion. We need this for certain date fields (e.g. a birthdate). With the MomentDateAdapter this could be done as follows:

  imports: [MatDatepickerModule, MatMomentDateModule],
  providers: [
    {provide: MAT_MOMENT_DATE_ADAPTER_OPTIONS, useValue: {useUtc: true}}
  ]

It's possible that I've missed something and that this is already possible. Please let me know how if so.

Thanks in advance!

[the-ult]

Would be great if the documentation of https://material.angular.io/components/datepicker/overview#choosing-a-date-implementation-and-date-format-settings would have an example of the matDateFnsModule implementation.

It seems like it is different than the MatMomentDateModule (When looking at the .spec file

• Is adding the MatDateFnsModule with providers for the locales in your app/root enough? Or should you add the MatDateFnsModule to you ComponentWithDate(Picker) as well?

[Edit] Looking at the source: https://github.com/angular/components/blob/main/src/material-date-fns-adapter/adapter/index.ts I Would expect this to be enough:

app.module.ts

import { nl } from 'date-fns/locale';
import { MatDateFnsModule } from '@angular/material-date-fns-adapter';

@NgModule({
  declarations: [],
  imports: [
    MatDateFnsModule
  ]
  providers: [
    { provide: LOCALE_ID, useValue: 'nl-NL' },
    { provide: MAT_DATE_LOCALE, useValue: nl },
  ],

my-date.component.ts

@NgModule({
  declarations: [],
  imports: [
 //    MatDateFnsModule // NOT needed here again..
  ],

Correct?

[Retry9997]

Adding to that documentation issue, I would like to note that it isn't clear how to resolve a particular locale object for MAT_DATE_LOCALE in projects that support multiple locales. Is this only possible by including all possible locale objects and mapping at runtime? An example or just a small footnote would be helpful when this is being documented.

[Tyler-V]

Day.js please :)

[Blackscr33n]

Dayjs should have been the top prio as it should replace moment. Sad to see that this is the only one missing.

[yanzacheus]

Hi, is it possible to know if it is still in progress, any status quo ? I chose to work with dayjs, but if it's no more in the roadmap of angular material or will be released much later, perhaps it's better for me to try another lib like date-fns, even if the migration is less simple.

[bgpedersen]

Any updates on dayjs adapter ? I tried to make it myself, but I can't make it work, and the docs doesn't give away any example of how it should be done. Would also be nicer to use a official supported adapter for dayjs, instead of a custom made one.

[hakimio]

They have decided against adding any new officially supported date adapters a long time ago. So, if you really need it, you have to check their implementation and do it yourself.

[DerHerrGammler]

Are their any work on dayjs these days? Dayjs is much smaller than the other options so it would be very great if we could get aimplementation of it.