Skip to content

[BUG]: hoveranywhere / clickanywhere return incorrect timestamps for date axes with local time zones #7816

Closed

Description

@Domino987

Description

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.

Reproduction

JSFiddle: https://jsfiddle.net/mky0s84a/1/

Using the following setup:

const startOfDay = new Date();
startOfDay.setHours(0, 0, 0, 0);

const now = new Date();

const layout_time = {
  xaxis: {
    type: 'date',
    range: [startOfDay, now]
  },
  hoveranywhere: true,
  clickanywhere: true
};

gd.on('plotly_hover', function(data) {
  console.log(new Date(data.xvals[0]).toISOString());
});

gd.on('plotly_click', function(data) {
  console.log(new Date(data.xvals[0]).toISOString());
});

Steps to Reproduce

  1. Open the JSFiddle.
  2. Hover or click at the extreme left side of the plot area.
  3. 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.

Environment

Activity

  1. godfengliang commented on Jun 1, 2026

    @godfengliang

    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.

  2. added a commit that references this issue on Jun 1, 2026
    5e252a3
  3. camdecoster commented on Jun 10, 2026

    @camdecoster
    Contributor

    Thanks for the bug report! We'll be talking about this as a team soon and will follow up.

  4. robertclaus commented on Jun 17, 2026

    @robertclaus

    @emilykl is following up on some nuances this touches on related to timezones this week.

  5. Domino987 commented on Jul 29, 2026

    @Domino987
    ContributorAuthor

    @robertclaus any news on this?

  6. camdecoster commented on Aug 5, 2026

    @camdecoster
    Contributor

    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.

  7. added this to the v4.0.0 milestone on Aug 28, 2026
  8. emilykl commented on Aug 28, 2026

    @emilykl
    Contributor

    Fixed by #7964.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions