d3/d3-time-format

Deprecate in favor of date.toLocaleString?

mbostock opened this issue · 7 comments

mbostock commented

I’m currently considering the long-term plan for this library.

JavaScript’s native support for localized date and time formatting has improved dramatically since D3 was first created (and pv.Format.time in Protovis before that). In particular, the fact that date.toLocaleString automatically uses the browser’s current locale is such a huge improvement (less en-US-centric) that I feel promoting d3-time-format’s continued use is harmful.

https://observablehq.com/@mbostock/date-formatting

There is also a nice standard for relative time format, Intl.RelativeTimeFormat:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/RelativeTimeFormat

It hasn’t made it to Edge and Safari yet, but Edge will eventually be Chromium, and Safari will hopefully come around. I expect therefore it would be better to encourage adoption of the standard and perhaps offer a polyfill than to compete with the proposed standard.

mbostock commented

I have noticed that date.toLocaleString is extremely slow, but perhaps browser vendors haven’t realized that and will make performance improvements as it is adopted by web developers.

mbostock commented

Since there is no standard for parsing dates (yet), it probably makes sense to retain part of this library as a D3 module that only implements parsing (not formatting). But I think it should be optional as most people should be using ISO 8601 to represent machine-readable dates and not using arbitrary localized formats in local time.

We also probably want a strict ECMAScript IEEE 8601 date parser in d3-time or somewhere central, and probably a shorthand formatter as well, since browser support for that is not quite where it should be and there is still an active TC39 proposal to standardize the behavior of Date.parse.

curran commented

FWIW, date.toLocaleString seems to have pretty good coverage - everything except Android webview.

image

mbostock commented

Unfortunately date.toLocaleString is far too slow for many applications (e.g., when formatting thousands of dates for static tooltips). But I haven’t yet tested whether creating an Intl.DateTimeFormat instance would be faster. If it is, that may be a viable replacement for this library.

curran commented

A benchmark would be good to have on hand, so we could easily check if browser vendors make performance improvements. Is there an example you know of that demonstrates or measures the slowness?

mbostock commented

I think this library still serves a purpose, at least as far as parsing goes, and it’s nice to have symmetry with formatting. Therefore closing this issue.