Support internationalizable date formats

[benmccann]

format right now:

	format: function(time, format) {
		return create(time).toFormat(format);
	},

Luxon recommends toLocaleString and discourages toFormat

Ideally the datetime adapter would support both:

	format: function(time, format) {
		return typeof format === 'string' ? create(time).toFormat(format) : create(time).toLocaleString(format);
	},

We may also want to change the default formats to something like:

var FORMATS = {
	millisecond: 'h:mm:ss.SSS a',
	second: DateTime.TIME_WITH_SECONDS,
	minute: DateTime.TIME_SIMPLE,
	hour: { hour: 'numeric' }, // or DateTime.TIME_SIMPLE?
	day: DateTime.DATE_FULL,
	week: 'DD',
	month: DateTime.DATE_MED,
	quarter: "'Q'q - yyyy",
	year: { year: 'numeric' }
};

This is a mix of internationalizable and non-internationalizable datetime formats since Intl.DateTimeFormat does not support quarters, weeks, or milliseconds. However, users will not see any impact of mixing internationalizable and non-internationalizable datetime formats unless they set a locale and use one of these formats. By default, the week and quarter formats are not used and the millisecond format is not heavily used either, so this would allow users to more easily internationalize the majority of the time.

[aried3r]

Hey, I was just looking into writing my first adapter for dayjs which is largely API compatible to Moment.js (see first quote in README), so I took the adapter used in Chart.js and s/moment/dayjs/.

But I also faced the problem of i18n, for example the default adapter uses 12-hour time and displays am/pm as well.

I couldn't really find out where and how this might get replaced by the proper, localized formats within Chart.js. I see that Luxon seems to solve it by using constants (DateTime.SOMETHING) instead of having to supply your own format string. But my question is more general, since there's also chartjs-adapter-date-fns which hardcodes the formats.

From what I've gathered so far, because of how Luxon, date-fns, dayjs etc work there is no easy way to localize these formats within Chart.js, or am I missing something?

I'm sorry if this is the wrong place to ask, and I'll gladly move this somewhere else if there are more appropriate channels for this.

[benmccann]

because of how Luxon, date-fns, dayjs etc work there is no easy way to localize these formats within Chart.js, or am I missing something

This is very dependent upon the specific library being used. Each will have a different solution. This ticket suggests a relatively straightforward solution for the Luxon adapter. This solution would work for date-fns as well if using the date-fns-tz package. dayjs does not yet have a way to use the browser's Intl api, so you currently would need to import a locale file for that specific locale. Or the other option would be to first update dayjs to use the Intl api iamkun/dayjs#498.

[simonbrunel]

@benmccann do you want to submit a PR with these suggested changes?

[aried3r]

dayjs does not yet have a way to use the browser's Intl api, so you currently would need to import a locale file for that specific locale.

I think that would be something a lot of people are either already doing or would be fine with. I have a local version of what could be a chartjs-adapter-dayjs which uses the LocalizedFormat plugin.

Anyway, this is probably the wrong place to discuss this. Would be the main Chartjs repo be better to discuss a potential, official chartjs-adapter-dayjs package?

[simonbrunel]

I think that would be something a lot of people are either already doing or would be fine with.

I also think we should use localized formats, built-in as suggested in the description of this ticket.

Would be the main Chartjs repo be better to discuss a potential, official chartjs-adapter-dayjs package?

If you are interested in developing and maintaining such adapter, I would start a personal repository (aried3r/chartjs-adapter-dayjs) based on the structure of this repo or the date-fns one depending which one have the most similar API as dayjs.

To promote it, I would first comment every tickets in the main repo that request a dayjs adapter, with a link to your project, and as soon as it's stable and ready for production, I would open a PR in the awesome repository.