You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[BUG]: hoveranywhere / clickanywhere return incorrect timestamps for date axes with local time zones #7816
The new hoveranywhere and clickanywhere functionality introduced in PR #7707 appears to return timestamps in ms since 1970 for the UTC (or axis-internal time) instead of the actual hovered/clicked data coordinate in local time.
In the example, when hovering or clicking at the very beginning of a date axis range that starts at local midnight, the returned timestamp is shifted by the local timezone offset.
Hover or click at the extreme left side of the plot area.
Inspect the logged value from data.xvals[0].
Expected Behavior
The returned value should correspond to the actual x-coordinate under the cursor.
For a user in UTC+2, hovering/clicking at local midnight on 2026-05-31 should return:
2026-05-30T22:00:00.000Z
because that is the UTC representation of local midnight.
Actual Behavior
The returned value is:
2026-05-31T00:00:00.000Z
which corresponds to midnight UTC rather than the hovered local-time position on the axis.
Notes
The axis range is initialized using JavaScript Date objects in local time.
The issue is reproducible for both hoveranywhere and clickanywhere.
Existing point hover behavior appears to correctly account for timezone conversion, while the anywhere-events seem to return a different timestamp basis.
It looks like the coordinate returned by data.xvals[0] may be using an internal UTC axis value instead of the user-visible axis coordinate.
I've opened PR #7818 to fix this. The issue is that ax.p2c() on date axes returns a display-time value (local-time components encoded as UTC ms) rather than true UTC milliseconds. The fix applies a timezone correction after the p2c call in the hover handler to convert back to true UTC ms, matching what trace data points return.
Activity
godfengliang commentedon Jun 1, 2026
I've opened PR #7818 to fix this. The issue is that
ax.p2c()on date axes returns a display-time value (local-time components encoded as UTC ms) rather than true UTC milliseconds. The fix applies a timezone correction after thep2ccall in the hover handler to convert back to true UTC ms, matching what trace data points return.fix: correct date axis timezone in hoveranywhere/clickanywhere events
camdecoster commentedon Jun 10, 2026
Thanks for the bug report! We'll be talking about this as a team soon and will follow up.
robertclaus commentedon Jun 17, 2026
@emilykl is following up on some nuances this touches on related to timezones this week.
Domino987 commentedon Jul 29, 2026
@robertclaus any news on this?
camdecoster commentedon Aug 5, 2026
Another user created a PR to fix this issue. Our team is slated to review, but it will still be a bit before a fix is published.
emilykl commentedon Aug 28, 2026
Fixed by #7964.