Re: minor bug regarding time/date graphs

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

On Wed, 7 Apr 2004, Pieter-Tjerk de Boer wrote:

> If one gives the following commands in gnuplot (version 3.8k.3):
>   set xdata time
>   set timefmt x "%d %b %Y"
>   set xtics border mirror norotate "01 Jan 1999",3.1557e+07
>   set xra ["01 Oct 1998":"01 May 2004"]
>   p x
> one gets a (trivial) graph, with labels on the horizontal axis
> starting at 01/01/1999.

Consider yourself somewhat lucky, then.  I don't think sequence ticks have
ever worked well in gnuplot.  This has improved considerably, but I
wouldn't bet the farm on that stuff anytime soon.

> However, after saving this and then loading the resulting file
> into a freshly started gnuplot, the date axis labels starts
> at 01/01/2000.

That's indeed caused by the 'timefmt' being written to the save file
too late in the list.  Rearranging save_all() will fix that.

> Furthermore, the labels are all simply 'g' rather than numerical
> dates.

Hmm... this version here gives me a '9' instead.

That's because you didn't have an explicit "set format x" in your script.
So gnuplot had to invent a time/date format string for the x axis.  Such
invented format strings aren't written back into the 'set format'
variables, so after the commands you gave, 'show format' will still show
the default '% g' for all axes.

> - gnuplot puts the "set format x ...." line after the "set xdata time"
>   line, which apparently overrides the label format (implicitly?) set
>   by the latter.

No, that override only happens at 'plot' time, but it's sensitive to
whether you just never gave a 'set format' for that axis at all (i.e. it's
still in the default state), or you explicitly requested a particular
format.  Loading a saved file will look like an explicit request, and thus
will be honoured.

Using a script-reduction tool like the one Petr put on the gnuplot.sf.net
web pages will solve this mystery, by removing the 'set format x "% g"'
lines from the saved scripts.

The crucial variable is axis_array[].format_is_numeric.  It's set
to FALSE in the case at hand, and that's wrong.  I'll look into this.


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