Skip to content

Change pattern proposal: dateformat package to Intl.DateTimeFormat API

Old Pattern

We currently use dateformat to format dates, either directly or via our wrapper formatDate. Additionally to that pattern we use a lot of custom formatters.

New Pattern

Use Intl.DateTimeFormat and our wrapper createDateTimeFormat.

We shouldn't be creating formatters everwhere, but rather in a central location, maybe with a "format" enum or individual functions.

So the API could be like:

import {dateFormat, DATE_FORMATS} from '~/path/date_format_util.js' 

dateFormat(date, DATE_FORMATS.DateTimeLongWithTZ)
dateFormat(date, DATE_FORMATS.DateLong)
dateFormat(date, DATE_FORMATS.UTCDateTimeLongWithTZ)
dateFormat(date, DATE_FORMATS.ISODateTime)
dateFormat(date, DATE_FORMATS.ISODate)

or maybe it should be

import {DateTimeLongWithTZ, ISODateTime} from '~/path/date_format_util.js' 

ISODateTime(date)
DateTimeLongWithTZ(date)

Advantages of switching patterns

  1. Removing a dependency
  2. Intl.DateTimeFormat is twice as fast (benchmark TBA)
  3. Intl.DateTimeFormat is locale aware (24h vs am/pm, translations, etc.), understands timezones, etc.

Disadvantages of switching patterns

  1. Intl.DateTimeFormat doesn't have an API to format ISO dates.
  2. Intl.DateTimeFormat doesn't have a way to specify formats with letters (e.g. 'YYYY-mm-DD')

What is the impact on our existing codebase?

  • 38 files import dateformat
  • 42 files import formatDate

Reference implementation

Edited by Lukas Eipert