Re: change handling of time data for 5.0?

[Ethan A M. <sf...@us...>]

On Monday, 06 October, 2014 18:33:42 Karl Ratzsch wrote:
> Am 06.10.2014 um 17:01 schrieb sfeam:
> > On Monday, 06 October 2014 12:53:07 PM Karl Ratzsch wrote:
> > 
> >> Wasn´t the idea to deprecate "set xdata time" because it always
> >> changes the ticslabel format type? I don´t see how it is still
> >> necessary now, except for backward compatibility, of course.
> > 
> > 
> > I'm not following you here. If we deprecated "set xdata time",
> > wouldn't we just have to introduce another command that did the
> > same thing? What would be the point?
> 
> There is no need for a replacement, i think. timecolumn() and strptime()
> can handle all timedata input. Plus "_data time" is limited to certain
> columns, depending on the plot style, and it is limited to one format.
> 
> So in many cases, people cannot use "_data time" anyway. 

I think everyone agrees on that specific point.  That was why
timecolumn() got a 2nd parameter, even before this recent round of revision.

> For the sake of a uniform UI, i´d say don´t use it at all.

But there we run head-on into the policy for backward compatibility
if possible.  Yes you can now write scripts that do not use "set xdata".
But that by itself doesn't justify breaking old scripts that do use it.
And getting back to your other example, it's still convenient to say
   set xdata time
   set timefmt "%d-%b"
   set arrow 1 from "01-Jan", y0  to  "05-Sep",y0+ydel
rather than
   timefmt = "%d-%b"
   set arrow 1 from strptime(timefmt,"01-Jan"),y0 \
                           to strptime(timefmt,"05-Sep"),y0+ydel

> > The thing that we might want to change is that "set xdata time"
> > might stop _also_ affecting 'set xtics time'. That would make the
> > input/output separation more complete, but would not be backwards
> > compatible.
> 
> Ah. We´ve been talking under different presumptions. ;-)
> Here´s mine:
> 
> It´s rather impossible to really separate in/output with "set xdata
> time", because it´s nomenclature says "plot abscissa" when it really
> means "first input column".

The more important point is that it means "use timefmt specifiers
rather than normal C numeric format specifiers".  Without this flag,
the gnuplot parsing routines don't know which library routine to 
feed the format statement to.  That functionality is not tied to any
particular input column or file, since it is also relevant to position info
and in particular to axis ranges.   I think of "set xdata" as being
parallel in syntax to "set xrange". 

> As this can´t be fixed, i say keep it for backward compatibility, but rebuild
> the functionality otherwise.

Exactly.
But "keep it for backward compatibility" is opposite to "deprecate it",
right?

> One small thing is still missing, imho: "set arrow" et al. should check
> if coordinates are set to time mode with "set _tics" (as it checks for
> "xdata time" now), and use the format set via "set timefmt" in that
> case. (not the one used to format the tic labels.)

I'm confused.  I thought we agreed in a separate Email thread that
positional coordinates, including arrows, should continue to be considered
'input' (using xdata/timefmt) rather than 'output' (using xtics/format)?

Under the new scheme it would never be correct to mix these up,
using axis->tictype  (internal flag for "set xtics") to control use of timefmt,
which is controlled instead by axis->datatype (internal flag for "set xdata").

> Additional features are possible, of course:
> One could for example introduce something like "set data <colnum>
> {time|date|..} {format}" so people don´t have to use the lenghty
> timecolumn() function every time.

Sure, but let's leave that for later.  It would be a purely new feature,
so it  doesn't affect current discussions of compatibility or
syntax change.

	Ethan