Proposal: Official `Temporal`/`Intl` time adapter, as a path to no external date library requirement

[johanrd]

Feature Proposal

Chart.js’ time scale docs currently state:

“The time scale requires both a date library and a corresponding adapter to be present.”

With the JavaScript Temporal API and Intl.DateTimeFormat, the platform now provides the primitives needed for time parsing, calendar math, time-zone handling, and label formatting. This proposal suggests:

1. An official chartjs-adapter-temporal package that relies only on Temporal + Intl (no third-party date library).
2. A future core enhancement to automatically use this adapter when globalThis.Temporal is available, enabling the docs to eventually drop the “date library” requirement.

---

Context

Temporal is a Stage 3 TC39 proposal, and is already being used in production via polyfills:

Polyfill	Repo	Status
@js-temporal/polyfill	js-temporal/temporal-polyfill	Alpha release available
temporal-polyfill	fullcalendar/temporal-polyfill	Beta release available

It would be nice for the projects that have left the "old world" javascript date handling (via these polyfills) to not need to pull in date libraries "just" for chart.js.

---

Migration / compatibility

• This new adapter would be opt-in as chartjs-adapter-temporal and would work with the current time scale.

• Existing adapters (moment, dayjs, luxon, etc.) and docs remain unchanged initially.

• Future (non-breaking) enhancement:
  If globalThis.Temporal exists at runtime, Chart.js core could automatically use the Temporal adapter. Otherwise, behavior stays exactly as it is today.

  At that point, the docs could evolve to something like:

  “If Temporal is available, no additional date library is required. Otherwise, install one of the existing adapters.”

This provides a path to eventually remove the blanket requirement that “the time scale requires both a date library and a corresponding adapter.”

---

Considerations

• formats() (and time.displayFormats) would return Intl.DateTimeFormatOptions objects in this adapter, while other adapters continue to return string tokens
• Quarter / ISO-week labels are not directly built into Intl. Is a small amount of custom logic in the adapter (similar to how current adapters already special-case these) acceptable?

Possible Implementation

The adapter would implement the existing Chart.js date adapter surface using only platform APIs:

• parse(value)
  Normalize input to Temporal.Instant / Temporal.ZonedDateTime and return epoch milliseconds.

• add / diff / startOf / endOf
  Use Temporal.ZonedDateTime for calendar-aware and time-zone-aware math (including DST boundaries and month/quarter/year boundaries).

• format
  Use Intl.DateTimeFormat to produce tick/tooltip labels.

• formats()
  Return Intl.DateTimeFormatOptions objects (for each time unit) instead of moment-style format strings.

Time zone would be explicit via Temporal.ZonedDateTime, rather than implicit in the host environment.

[etimberg]

This definitely seems like a good enhancement. Not sure when I'd personally have time to work on something like this, but I can happily get someone set up to develop it

[peterjthomson]

This sounds like such a sensible migration path / shim approach. Love it!
We bundle several date adapters into Laravel ChartJS and would love to have a 'no-external dependancies' option.