Bar length in milliseconds

[nicolaskruchten]

Right now we can specify bar lengths in milliseconds on date axes but this is interpreted in a browser-timezone-dependent manner, which seems like a clear bug that makes this feature unusable. See https://codepen.io/nicolaskruchten/pen/qBOKdQG ...

Basically, the following figure JSONs (which differ only in x) should probably have the same output, regardless of timezone of browser:

{
"data":[{"base":["2020-02-06 00:00"],"orientation":"h","type":"bar",
"x":[86400000],"y":[1]}],
"layout":{"xaxis":{"type":"date"}
}
}

{
"data":[{"base":["2020-02-06 00:00"],"orientation":"h","type":"bar",
"x":["1970-01-02 00:00"],"y":[1]}],
"layout":{"xaxis":{"type":"date"}}
}

[nicolaskruchten]

This is actually a more general problem than "bar lengths", as shown in this scatter example: https://codepen.io/nicolaskruchten/pen/xxwzGBe ... it seems that we interpret numbers in milliseconds as timezone-dependent in general.

In fact, it's even funnier without the base in bars... the length is correct, but the base is moved back! https://codepen.io/nicolaskruchten/pen/LYprVoP

[alexcjohnson]

Bars on date axes are meaningless with no base - there's no such thing as zero. So while that's indeed funny behavior, I'm not inclined toward any sort of action to define one behavior as "correct".

In the scatter case we've long held this to be an unfortunate early decision that we're now locked into until we either make a new major or add explicit time zone handling. The issue is folks constructing their data client side as new Date(...).getTime() which bakes in the time zone offset, then we just take it back out while plotting - ie new Date('1970-01-02 00:00') is expected to behave the same as '1970-01-02 00:00'. I suppose we could have a discussion about whether we still view that use case as significant enough that changing it would constitute a breaking change - I'd love to do this in a v2 but I'm hesitant to make that change in v1.

For bars with base though I'm 100% on board with considering our interpretation of milliseconds a bug. Using the JS Date machinery to construct bar lengths with some arbitrary base would be extremely weird, and "x milliseconds" has an obvious meaning that we're not following. We should handle this in such a way that the existing date-string behavior is preserved.

[nicolaskruchten]

Bars on date axes are meaningless with no base - there's no such thing as zero

Well, we basically identify 1970-01-01 as zero in many contexts, so I could see us just reifying that...

[nicolaskruchten]

For bars with base though I'm 100% on board with considering our interpretation of milliseconds a bug

What about when the base is also specified in milliseconds?

[alexcjohnson]

we basically identify 1970-01-01 as zero in many contexts, so I could see us just reifying that...

we could, but I don't really see the point - does that help anyone? We should just push people to choose an explicit base.

What about when the base is also specified in milliseconds?

Then it should have the legacy timezone-dependent behavior, matching all other absolute position values on date axes, unless and until we change that behavior for scatter etc. Otherwise if you try to align two traces to each other you'd need to know which uses the timezone offset and which doesn't.

I really think that until we get around to either implementing real time zone support or releasing a v2, we just need to keep the existing meaning of absolute numeric positions on date axes, and make it self-consistent. For new projects (once we fix the bar length bug part of this) the recommendation is straightforward: use strings for absolute dates and milliseconds for relative dates.

[nicolaskruchten]

OK, let's tightly-scope this thing to just the cases when there is a base and the value is a number.

One thing that will come up then sometimes is that all your y values (in default orientation) would be numbers and all your base values would be dates... I think we should auto-detect the xaxis.type to date in this case... thoughts?

[archmoj]

Let's move this to at least a minor.