This change seems to have been introduced between version 0.8 and 0.9 of d3-scale
v0.8.0...v0.9.0

So probably somewhere here? d3/d3-time@v0.2.0...v0.3.0

It’s easier to see what’s happening with a linear scale (and the only difference between a time scale and a linear scale is that scale.invert calls new Date(time) to convert milliseconds since UNIX epoch back into a Date instance):

The domain is [2022-08-31T22:00Z, 2022-09-30T21:59:59.999Z] which is [1661983200000, 1664575199999]. The range is [0, 946].

The input is 2022-09-04T22:00Z which is 1662328800000.

The scaled output is 126.13333338199588 which is a * (1 - t) + b * t given t = (1662328800000 - 1661983200000) / (1664575199999 - 1661983200000), a = 0, b = 946.

Inverting the scaled output back to the input is 1662328799999.9998, which is a * (1 - t) + b * t given t = (126.13333338199588 - 0) / (946 - 0), a = 1661983200000, b = 1664575199999. This is less than the input by 0.000244140625ms, but within the expected floating point precision (0.9999999999999999×).

The issue arises that new Date(number) floors the input. And hence new Date(1662328799999.9998) is equivalent to new Date(1662328799999), which is off by 1ms, for an error of 0.9999999999993985×. This is a ~4,000× increase in error due to millisecond rounding.

To improve this, we need to call new Date(Math.round(number)) instead.

Recently we ran into this issue too and we finally figured out this was causing it (we use the invert method on the time scale as well). Is there any reason why this PR has not been merged yet?