vega/vega-lite

UTC dates don't display properly in tooltips

jakevdp opened this issue · 14 comments

Here is a short example (open in editor):

{
  "data": {"values": [{"date": "2021-01-01"}]},
  "mark": {"type": "square", "size": 500},
  "encoding": {
    "tooltip": {
      "field": "date",
      "timeUnit": "utcyearmonthdatehours"
    },
    "x": {
      "field": "date",
      "timeUnit": "utcyearmonthdatehours"
    }
  }
}

Screen Shot 2021-01-25 at 3 04 09 PM

Despite showing identical fields with identical timeUnits, the date shown in the tooltip and the date shown on the axis label disagree.

Note that a workaround is to use "scale": {"type": "utc"} in the tooltip (view in editor), but I don't think this should be necessary:

{
  "data": {"values": [{"date": "2021-01-01"}]},
  "mark": {"type": "square", "size": 500},
  "encoding": {
    "tooltip": {
      "field": "date",
      "timeUnit": "utcyearmonthdatehours",
      "scale": {"type": "utc"}
    },
    "x": {
      "field": "date",
      "timeUnit": "utcyearmonthdatehours"
    }
  }
}

Screen Shot 2021-01-25 at 3 08 14 PM

It looks like this also affects the text encoding, which makes the issue easier to see (open in editor):

{
  "data": {"values": [{"date": "2021-01-01"}]},
  "mark": "text",
  "encoding": {
    "text": {"field": "date", "timeUnit": "utcyearmonthdatehours"},
    "x": {"field": "date", "timeUnit": "utcyearmonthdatehours"}
  }
}

visualization (31)

I am experiencing the same problem here. It is a pretty big issue for us and is blocking on going to production since data integrity is very important

image

Ahh, the joy of time zones again.

@rnvarma can you look into what's going on in the Vega specs? It would help us immensely scope the effort for the fix.

the config for the x encoding above is:

{
  field: "created",
  title: "Created",
  type: "temporal",
  timeUnit: "utcyearmonthdate",
  axis: { format: "%b %d" },
}

The date value itself in the data is 2020-08-04T00:00:00. It is correctly using UTC for the x axis value, but in the tooltip converting to local time and going back to the previous day

I'm also running into this for point charts. Apologies if this isn't a minimal example, I'm new to Vega-Lite.

{
  "$schema": "https://vega.github.io/schema/vega-lite/v5.json",
  "data": {
    "values": [
      {"Date": "2020-01-01", "Value": 10}
    ]
  },
  "mark": {"type": "point", "tooltip": true, "point": true},
  "height": "container",
  "width": "container",
  "encoding": {
    "x": {"field": "Date", "type": "temporal"},
    "y": {"field": "Value", "type": "quantitative"},
    "opacity": {"condition": {"param": "hover", "value": 1}, "value": 0.1},
  },
  "title": {"text": "Diff"},
  "params": [
    {
      "name": "hover",
      "bind": "legend",
      "select": {"type": "point", "fields": ["symbol"]}
    }
  ]
}

image

Open the Chart in the Vega Editor

marr commented

@jakevdp Do you plan to upgrade the altair version so it supports scale on the tooltip?

marr commented

Still running into this issue. Any ETA for a fix?

I haven't had cycles to look into this yet. Can you investigate and maybe send a pull request?

marr commented

I can take a look. I had thought the workaround wasn't working, but it actually does. The schema has a squiggle under the value, but I am learning that shouldn't always be trusted.

Anyone find a solution for this issue yet? I was going crazy thinking there was an issue with my data or how my data was read by altair, but finally realized it's an error in how altair renders the mark line tooltip.

marr commented

You can add "scale": { "type": "utc" } to the encoding as a workaround.

My PR fixes the issue but I wasn't able to get it merged because of the github access token. It still might be worth trying to merge that, @domoritz

That worked - thank you!

You can add "scale": { "type": "utc" } to the encoding as a workaround.

My PR fixes the issue but I wasn't able to get it merged because of the github access token. It still might be worth trying to merge that, @domoritz

Did that PR make it in? If so, what version fixes this?

marr commented