Date ticks overhaul

[jkrumbiegel]

This PR changes the way that ticks for datetime axes are located and formatted by default. The new tick formatting reduces the amount of redundant information by printing time on a separate line from date (if time is different from 0). This way, the date only has to be shown whenever it changes from tick to tick. Similarly, only the time component of the tick step size is usually shown, unless there's a step in the parent component. For example, seconds would be shown :58, :59 but then as the minute changes, the full time is shown like 03:17:00 and then further :01, :02, etc.

Fixes #4404, fixes #3972, fixes #3959

This PR

f = Figure(size = (600, 800))
data = cumsum(randn(12))
for (i, T) in enumerate([Year, Month, Day, Hour, Minute, Second, Millisecond])
    times = DateTime(2025, 06, 30, 17, 54, 56, 993) .+ T.(1:12)
    lines(f[i, 1], times, data)
    Label(f[i, 2], "$T", rotation = pi/2, font = :bold, tellheight = false)
end
f

Master

This PR also adds a separate dispatch route for datetime ticks which fixes the bug that the ticks or the tick format could not be changed manually and were always hardcoded to the automatic tick finding algorithm.

dates = Date(2025, 06, 30) .+ Day.(1:5)
data = cumsum(randn(5))

with_theme(Axis = (; yticksvisible = false, yticklabelsvisible = false, ygridvisible = false)) do
    f = Figure()
    lines(f[1, 1], dates, data)
    lines(f[2, 1], dates, data; axis = (; xticks = (dates[[1, 2, 3, 5]], ["A", "B", "C", "E"])))
    lines(f[3, 1], dates, data; axis = (; xtickformat = "e, d.m.yyyy"))
    f
end

[MakieBot]

Benchmark Results

SHA: b0f16679bf786df8850beaae4864a3321e6ee89e

Warning

These results are subject to substantial noise because GitHub's CI runs on shared machines that are not ideally suited for benchmarking.

[jkrumbiegel]

One question for review is whether get_datetime_ticks, get_datetime_tickvalues and get_datetime_ticklabels are needed in addition to the existing get_ticks, get_tickvalues and get_ticklabels. The reason I added them is that the others work with float vmin vmax values and I assumed one could get ambiguities relatively easily if one suddenly started to dispatch on the vmin, vmax arguments, too. Currently, these are not used for dispatch as they are always float, some methods may annotate the types and some may not.

[jkrumbiegel]

Ok I've decided to remove the date-specific functions after all and simply use dispatches on vmin::DateTime, vmax::DateTime. That seemed to work ok as well, let's see if CI surfaces any ambiguities.

I've also left in the scale even though it probably doesn't make sense to use it with a DateTime axis. But this way it's consistent with the other functions.

[nilshg]

This is amazing, thank you so much!