Time/date autoticking --- showstopper?

[Hans-Bernhard B. <br...@ph...>]

Gents,

it seems we may have found ourselves a show-stopping bug:

 [ 918276 ] Irregularly spaced labels on time axis in v 3.8k.2

Thanks to Chistopher Roth (cc'ed) for spotting this one.

The culprit who committed the code in question is myself, but given the
schedule of the planned release, I think we'll need all attention we can
muster focussed on that one.  I for one won't consider the program to be
release-worthy until we fix it.  (It's marked as release_critical for that
reason.)

To easily see what the problem is, try the following script:

	reset
	set ydata time
	set mytics
	p [-10 : 36*60] x

Replace the numbers by whatever you like, and watch the y tics.  
Optionally set the ytics or mytics to some explicit interval.

There's a *lot* of funny things going on there.  The minitics are
seriously ill, but the major tics aren't exactly perfect either.  The
functions and data to inspect are all in axis.c:

	t_timelevel timelevel[];
	AXIS axis_array[];

	quantize_duodecimal_tics()
	quantize_time_tics()
	make_auto_time_minitics()
	time_tic_just()

The main problems seem to be that interpretation of timelevel[] is
somewhat different between quantize_time_tics() and time_tic_just().

Since I invented quantize_duodecimal_tics(), timelevel[] is set by
quantize_time_tics() to be the unit the major tic spacing it's *based* on.  
In particular, that unit is quite often *larger* than the actual tic step,
i.e. a tick step of 10 minutes is seen as "1/6th of an hour", so
timelevel[] will be TIMELEVEL_HOURS.  time_tic_just() does quite a number
of wrong things if tics are spaced as fractions of a timelevel[] unit. In
particular it moves tics around by zeroing out fields in a time struct,
causing them to often end up all in the same place. Christopher posted a
patch for this, but IMHO that's not exactly correct either.

Time axes are actually not all that bad, even --- the strange factor of
twelve is tricky, but quantize_duodecimal_tics() can handle it.  The real
bugger is with date axes.  These are (slightly, but significantly)
irregular by definition, and that's not something the usual auto-ticking
algorithm can do. In trying to get those right, it's very easy to break
other aspects, and we did.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.