I don't really understand what's going on here, but strange things happen when I start interacting with this graph - a tiny drag and the ticks jump back to the incorrect "before" position. I think we need to resolve this at an earlier stage in the process.

I don't really understand what's going on here, but strange things happen when I start interacting with this graph - a tiny drag and the ticks jump back to the incorrect "before" position. I think we need to resolve this at an earlier stage in the process.

Good catch. In fact it was previous commit a4cb02b that contributed in this bug.
For now I reverted part of it in ecb5067.
Now investigating if we could possibly resolve it earlier in the process.
Thanks.

@alexcjohnson please note that the tick0 tweaking part was removed in 5d61cef.

Then commit 77a51d3 was enough to fixe the bug.

And c42358c as well as b78a80b basically moved most of the period logic into functions i.e. to help minimize the calcTicks function.

Much cleaner! But there's still one issue here, because the auto dtick prior to considering tickformat is weeks, the auto tick0 is '2000-01-02', hence the tick you see is on Jan 2. But then when you zoom out so the auto dtick is months, tick0 and the ticks you see jump back to the first of the month.

Seems to me like either adjustPeriodDelta needs to also adjust tick0, or perhaps even cleaner, the whole adjustPeriodDelta logic could be pushed into axes.autoTicks?

Much cleaner! But there's still one issue here, because the auto dtick prior to considering tickformat is weeks, the auto tick0 is '2000-01-02', hence the tick you see is on Jan 2. But then when you zoom out so the auto dtick is months, tick0 and the ticks you see jump back to the first of the month.

Seems to me like either adjustPeriodDelta needs to also adjust tick0, or perhaps even cleaner, the whole adjustPeriodDelta logic could be pushed into axes.autoTicks?

Good eye.