Here’s an example where it breaks and I’m not sure yet what to do:

Plot.plot({
  x: {interval: "4 weeks", ticks: "months"},
  marks: [Plot.barY(aapl, Plot.groupX({y: "median", title: "min"}, {title: "Date", x: "Date", y: "Close"}))]
})

It breaks because the 4 weeks interval doesn’t align with the months interval (because weeks by default start on Sunday, and months start on whatever day they start at). Perhaps, for example, we have to floor the generated tick values according to the other interval?

Okay, I’ve done what I suggested above.

Plot.plot({
  x: {interval: "4 weeks", ticks: "year"},
  marks: [Plot.barY(aapl, Plot.groupX({y: "median", title: "min"}, {title: "Date", x: "Date", y: "Close"}))]
})

It’s a little surprising, perhaps, since that 2013 actually corresponds to December 29, 2013.

Plot.plot({
  x: {interval: "4 weeks", ticks: "year", tickFormat: Plot.formatIsoDate},
  marks: [Plot.barY(aapl, Plot.groupX({y: "median", title: "min"}, {title: "Date", x: "Date", y: "Close"}))]
})

That’s because January 1, 2014 rounds down to December 29, 2013 when using the 4 weeks interval, but the default time format sees the ticks about a year apart, and hence only shows the year. It might be better therefore to round up rather than down, but technically our RangeImplementation interface only guarantees that interval.floor is available. But I think we could reasonably introduce a requirement that you implement interval.ceil, too, or at the very least use it if available.

With interval.ceil, it’s more consistent with the default behavior.

Plot.plot({
  x: {interval: "4 weeks", ticks: "year"},
  marks: [Plot.barY(aapl, Plot.groupX({y: "median", title: "min"}, {title: "Date", x: "Date", y: "Close"}))]
})

Although now I notice that the default ticks are broken with the 4 weeks interval… 😬

Plot.plot({
  x: {interval: "4 weeks"},
  marks: [Plot.barY(aapl, Plot.groupX({y: "median", title: "min"}, {title: "Date", x: "Date", y: "Close"}))]
})

A nice property would be if e.g. “2018” always meant the same thing in the default time axis, i.e. 2018-01-01. So perhaps a better strategy here would be:

1. Compute the positive integer n such that taking every nth value from the scale’s domain produces as close as possible to the desired number of ticks. For example, if the domain has 100 values and 5 ticks are desired, n = 20.
2. Compute the median step s between adjacent values from the scale’s sorted domain, and use this to determine the standard time interval i that is closest to the median step s times n (per 1). For example, if the scale’s interval is day and n = 20, then i = month; if the scale’s interval is day and n = 7, then i = week.
3. If the standard interval i (per 2) is subsumed by the scale’s interval, i.e. if the ticks generated by i are not altered by the scale’s interval, then use the standard interval i to generate ticks with the default multi-line conditional format. For example, if the scale’s interval is day and i = week, use week ticks.
4. Otherwise, use n (per 1) to select every nth value from the scale’s domain, and apply the default ISO date format. For example, if the scale’s interval is week and i = month and n = 3, use every third week as YYYY-MM-DD.

The nice thing about this strategy is that it avoids needing to know exactly what the scale’s actual interval is; the scale’s interval can be a black box, and we can infer everything from applying the interval and looking at domain values.

Got some pieces working here: https://observablehq.com/d/61f1586d16d3ec0c

Now also addresses part of #74 when a numeric interval is specified.

I went through several iterations on this and I feel this is now ready this is still not quite ready.

I explored dropping tick labels instead of dropping ticks. I feel this produces a better result in some cases:

However, I decided against it because it feels in consistent. For example, if you specify ticks as an array of values, we only draw those, but if you specify ticks as an interval or a number, or you use tickSpacing, you get ticks for every value in the domain but only some of them are labeled. And if you specify the tickFormat option, suddenly all the ticks appear regardless of the interval option? I could see there being a version of this approach that works in the future, but I think we need more options, or to redesign the existing options, to make it work.

I also explored how we handled “misaligned” intervals. For example, what do we do if the scale interval is 4 weeks, but the tick interval is year? These two intervals are not aligned (there are 365 or 366 days in a year, which is not a multiple of 28). One strategy that worked fairly well is to draw the first tick in each interval. So, the first 4 week interval within each year interval has a tick, like so:

The logic for this is:

data.filter((d, i) => (i === 0 || ticks.floor(d) > ticks.floor(data[i - 1]));

However, I think computing the intersection of the intervals is simpler and easier to understand:

data.filter((d) => ticks.floor(d) >= d);

And perhaps more importantly, it avoids the problem of the first and second tick being likely to overlap.

But I also realized that there’s a more general problem: even if the intervals are aligned, the tick interval could be much farther apart than a “standard” time interval, making the default multi-line time format inappropriate. For example, if you have the 52 week tick interval on top of a 4 week scale interval, and you try to display that using the default multi-line format for 4 week (which is day, %-d %b), you get this:

I attempted to avoid this problem by checking if most of the ticks were dropped by applying the tick interval, and switching to the default ISO format. But writing this up, I realize we have the same problem even if you don’t specify the tick interval at all and you just specify a scale interval of 52 weeks:

So… I’ll put this back in draft mode. 🤔 I’m guessing maybe the multi-line format has to be smarter about comparing with the previous tick value; it can’t rely solely on whether the partial format is the same (because e.g. “Nov” could refer to Nov 2014 or Nov 2015).

And there’s still an outstanding problem that we don’t have a way of indicating whether intervals associated with an ordinal scale are in local or UTC time, so for the most part we default to UTC time. This means if you have an ordinal time axis with hourly data, there’s no easy way to get the multi-line format to show local time. I think this will require a new option, or perhaps exposing the multi-line format.

Okay! Ready to go! 🚀

There’s still some room for improvement here, but I wonder if it’s a blocker. In the example in the top post, we no longer generate yearly ticks, but instead generate monthly ticks every 8 months:

Plot.plot({
  x: {interval: "month"},
  marks: [Plot.barY(aapl, Plot.groupX({y: "median", title: "min"}, {title: "Date", x: "Date", y: "Close"}))]
})

It would be nicer in this case if we could use aligned 6 months ticks instead:

Plot.plot({
  x: {interval: "month", ticks: "6 months"},
  marks: [Plot.barY(aapl, Plot.groupX({y: "median", title: "min"}, {title: "Date", x: "Date", y: "Close"}))]
})

Or, if you prefer, year ticks:

Plot.plot({
  x: {interval: "month", ticks: "year"},
  marks: [Plot.barY(aapl, Plot.groupX({y: "median", title: "min"}, {title: "Date", x: "Date", y: "Close"}))]
})

The challenge is that it can be hard to know which interval is specified, and therefore how to generalize it. It seems obvious in the case that the interval option is month (the string), but you could set it to d3.utcMonth, or d3.utcMonth.every(3), or some such, and we’d have a harder time detecting that this is a “standard” interval and therefore know how to generalize it automatically to reduce the number of ticks. That’s the appeal of simply showing every nth tick. But we could perhaps treat named intervals specially.

Okay! The latest commit detects and generalizes standard time intervals, so we get the best possible result for the common case where the scale’s interval is something common like month or day.

Plot.plot({
  x: {interval: "month"},
  marks: [Plot.barY(aapl, Plot.groupX({y: "median", title: "min"}, {title: "Date", x: "Date", y: "Close"}))]
})

I believe I’m done polishing this now. I feel like even though this was a long journey, the resulting logic isn’t too complicated. Let me know if I can clarify anything, @Fil.

None of the above comments is blocking.

I poked at the downloadsOrdinal example a bit and maliciously tried x: {interval: 1} instead of "day". My browser didn't let me create an ordinal scale of a bazillion instants (one per ms), which is fortunate. I wonder though if there should be more of a control on this, beyond the browser balking with a RangeError: Invalid array length. Maybe not, but the error message is not super friendly.

(Note that x: {interval: "second"} takes a dozen of seconds but ends up returning a chart — except of course that the bars are too thin to be visible.)

Using temporal intervals & tickSpacing on the horizontal scale is really flowing. I'm adding a test that uses it on the fy facet scale.