Tick labels when using hourly rangebreaks

This pen https://codepen.io/nicolaskruchten/pen/qBdwQKw?editors=0010 shows oddly-spaced tick labels both by default, and when setting dtick to 24*60*60*1000 (daily) or 60*60*1000 (hourly).

[alexcjohnson]

There are 2 pieces of this: first, both hour and day ticks have positioning bugs if you use dtick explicitly:

• the day tick labels are in the wrong places even for what they say they are (if you look at the “April 7 2020” tick, it’s actually at 16:00 on that day - why? That makes no sense, tick0 on that axis is an exact day (in fullLayout) so the tick should be at midnight, ie mid-break, so it should appear at the end of the break, or 09:00. And the April 6 tick is missing entirely.
• in hour mode two or more overlapping tick labels at the same location?

Second is the question about how to display nice evenly-spaced ticks. I don’t think this will be a problem with day ticks, once the bug part is solved those will be fine. But hour ticks are an interesting case. 1-hour dtick should be fine, unless users start specifying nightly breaks in increments of fractional hours… at that level of generality there’s probably nothing we can do to ensure even tick spacing, we’ll just need to live with funny spacing near the break. The multi-hour dtick values we have in our auto-dtick output are 2, 3, 6, and 12 hours, and none of those will make sense in all conditions, but going straight from 1 hour to 1 day won’t be a great experience (even for 8-hour workdays that’s a factor of 8 jump) so we need something in the middle. A proposal:

• use a rounded form of bounds using the floor of the first item and the ceil of the second, to get a firstHour and numHours
• shift tick0 to firstHour on some date, when using dtick more than 1 and less than 24 hours
• try to find a reasonable algorithm for intermediate hours based on numHours. Maybe we always include “half the range” as Math.ceil(numHours / 2) - even though that will already be nonuniform for odd numHours - and continue halving until we get to <=3? Or first try to factor numHours and use all the factors, switching to this halving thing only if numHours is prime?

[alexcjohnson]

@archmoj let’s split this issue into two pieces, as I describe in my comment, so we can be very clear about the behavior we’re targeting:

• If you explicitly specify tick0 and dtick, those should be respected exactly, but if any given tick falls inside a rangebreak, its displayed position should be moved to the very end of the break and only the tick closest to the end of the break should actually be displayed if there are multiple within the break.
• If we’re picking tick0 and dtick for you, we should pick values that maximize uniformity of spacing, but after having chosen a tick0 and dtick the behavior should follow the behavior of the first point.

Image tests may not be the best way to cover this, especially the second part. Certainly one or two images but jasmine tests will let us lock down many more cases. We want many different axes showing all spans of range (leading to any autodtick from 1 to 24 hours, with a focus on the values between 1 and 24 but showing exactly where we transition from 1 or 24 to the next intermediate value) and different spans of hour rangebreaks (removing anything from ~4 hours up to ~20 hours with different starting points. The most common I guess will be removing either 8 hours (eg [0, 8] or [21, 5]), 12 hours (eg [21, 9], [20, 8]), or 16 hours (eg [16, 8] or [17, 9]), maybe 15 too (eg [17, 8] or [18, 9]) so you see 9 hours in a day, showing both ends of an 8-hour workday ie 9am and 5pm or 8am and 4pm.