You need to sign in or sign up before continuing.
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
- Removing a dependency
- Intl.DateTimeFormat is twice as fast (benchmark TBA)
- Intl.DateTimeFormat is locale aware (24h vs am/pm, translations, etc.), understands timezones, etc.
Disadvantages of switching patterns
- Intl.DateTimeFormat doesn't have an API to format ISO dates.
- 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
- Not a reference implementation per se, but utilized it recently in gitlab-org/gitlab!65570 (merged) and gitlab-org/gitlab!65740 (merged)
- Will add a reference implementation here later.
Edited by Lukas Eipert