Deprecate in favor of date.toLocaleString? about d3-time-format

[mbostock]

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]

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.

[mbostock]

Here are the relevant bits from d3-dsv to parse and format ECMAScript dates strictly:

https://github.com/d3/d3-dsv/blob/ff2d09f943c2d19d0f0fa96f9b6a39c7431ca7e8/src/autoType.js#L9
https://github.com/d3/d3-dsv/blob/ff2d09f943c2d19d0f0fa96f9b6a39c7431ca7e8/src/dsv.js#L47

[curran]

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

[mbostock]

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]

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]

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.