year format heuristic

[Fil]

Format year-like numbers (integers in [1000, 3000]) without thousands separators on axes and tips.

Closes #768

This introduces two new helpers:

• isYearDomain(domain) — returns true if all finite numeric values are integers in [1000, 3000]; false for non-number types, empty domains; ignores NaN and Infinity
• formatYear(value) — formats as plain integer YYYY if the value is a number in [0, 9999] (or possibly yyyy.xyz if applied to a non-integer), returns "NaN" for NaN, else falls back to formatNumber(value) (once we decide to format without a comma, we do it over [0…9999] so that if 7000 unexpectedly appears, it is formatted consistently just like 2000).

When deriving an ordinal or linear scale, the data values are checked with isYearDomain, and a hint is added to the scale; in axes, the tickFormat then defaults to formatYear. For tips, when the channel is associated to the scale, we also check the hint; if there is no scale, we call isYearDomain too.

I chose to test [1000, 3000] for the heuristic (instead of, say, [0, 9999]), because the latter was generating many changes in snapshots. (The point is to have a heuristic that catches the most common cases while still being easy to remember; in that regard [1000, 3000] is slightly more complicated than[0, 9999], but it seems more useful that way — or maybe it is that I'm too accustomed to it?)

I wonder if we should:

• accept tickFormat: "year" as an option (DONE)
• export formatYear?

[csdiehl16]

looks good to me! I run into this all the time so this is a very useful feature. I think we just want to make sure it's clear to users how to override the default if needed.

Whatever LLM is writing all our code in the year 3001 will need to remember to update it!

[allisonhorst]

Looks good to me, too!

[allisonhorst]

I think this would be nice:

accept format: "year" as an option

[Fil]

I've implemented the (opt-in) "year" format. I don't think we need another opt-out than tickFormat: "," or some such.