interval.every can return intervals of inconsistent length

[mbostock]

It’s weird that d3.utcMonth.every(9) alternates between 3- and 9-month intervals since the field number resets when the year changes. It’d be more obvious if this irregular interval were called d3.utcYearMonth, like we do with d3.utcMonthDay. Same for local time.

Related #62 #63.

[mbostock]

There’s a similar issue with d3.utcHour and d3.timeHour: if you use d3.utcHour.every(5), you get a combination of 5- and 4-hour intervals since it resets at midnight; and if you pass a period greater than 24 such as d3.utcHour.every(48), it’s equivalent to d3.utcHour.every(24).

Maybe we don’t need new intervals — maybe we need to change the behavior of interval.every? We could have two variants of interval.every: one that returns strictly every nth interval (relative to UNIX epoch or some other arbitrary zero), while the other is allowed to reset to align within some parent interval (the current behavior). Or we even change the behavior of interval.every to be the strict variant (and deprecating unixDay since it will now be the same as utcDay). Would that require a major version bump? 🤔

It’s a challenge for d3.timeHour, though, since it would mean that d3.timeHour.every(6) is not guaranteed to return 12AM, 6AM, 12PM, 6PM because of daylight saving time; it might return 1AM, 7AM, 1PM, 7PM or 11PM, 5AM, 11AM, 5PM. That is unavoidable if the requirement is that the returned intervals are always six hours apart. 🤔 I think that suggests we need both, but maybe we only need both for d3.timeHour and everything else can have the strict behavior?