Re: change handling of time data for 5.0?

[sfeam <sf...@us...>]

On Sunday, 05 October 2014 03:27:34 PM Karl Ratzsch wrote:
> i just checked out the latest 5.1 cvs, and it seems to work just nicely.
> 
> Am 04.10.2014 21:00, schrieb sfeam:
> > plot <foo> using (Offset_2_weeks + timecolumn(N)):M
> > 
> > I don't see a way to catch that without adding additional bookkeeping

After making the large set of changes I went back and modified the 
parsing to handle "timecolumn" as a special case with a variable
number of parameters.  So this caveat no longer applies.

> 
> - Changing back to "set xtics numeric" keeps a previously set time
> formatstring, which then throws an error "Bad format character". 

The analogous problem was present before this change also:
version 4:

   set xdata time
   set format x "%b-%Y"
   plot [0:1e8]	# All fine
   unset xdata
   replot       # Bad format character

The only difference is that now you can trigger the same thing
with "set xtics".

> I think
> the different output format strings should be kept in separate
> variables, with default values for each. (Dang, that would break
> backward compatibility to some extent, depending on the order of
> commands. Perhaps store them in additional variables, and copy them to
> the actually used tics format variable whenever an "(un)set xdata time"
> or "set xtics time/numeric/.." command is issued. "set xtics format
> <fstring>" would only change the latter, then.)

That's what the version 4 code was doing (although it was not
documented). But it didn't avoid the problem above.
Maybe we can come up with a clever improvement.

> - The synonymous "set format x/y/x2/.. <formatstring>" command also
> needs the time/numeric/.. option.

I was thinking that putting the keyword there was an
alternative to putting in "set xtics".  But maybe you are
right that it should be allowed in either place. 
If you don't give any keyword at all in such a command,
would it reset to "numeric" or would it leave the current
setting unchanged?   I can see advantages either way.