Re: change handling of time data for 5.0?

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

On Saturday, 04 October 2014 08:37:17 PM Karl Ratzsch wrote:
> On 04.10.2014 02:17, Ethan A Merritt wrote:
> > On Friday, 03 October, 2014 15:04:07 Karl Ratzsch wrote:
> >> Would it be difficult to make the second parameter to timecolumn()
> >> optional, and use whatever is set via "set timefmt" if no format
> >> string is given?
> > 
> > Yes, it is possible to trap the case of a single parameter and
> > fall back to a default timefmt. That loses the ability to have
> > separate default formats for the x and y axes, but see below.
> > 
> > The whole idea of having the time format be per-axis rather than
> > per-datafile makes little sense to me. So I'm now thinking we could
> > remove the timefmt field from (struct axis) and have one global default.
> > This is in fact what the 4.6 documentation describes, even though
> > it hasn't been true for a very long time. So although it would
> > internally be a change, it would keep the previous documentated 
> > behavior. It would only affect scripts that used the undocumented 
> > command: set timefmt y "format".
> 
> Even that can be kept, imo. timecolumn() could check for a format
> string as (in that order) second parameter, in timefmt <colnum>
> (new), timefmt <x/y), general timefmt, and use the first it finds set.

That isn't possible, because at the level of interpretation where
f_timecolumn() receives control it has no idea which axis may or
may not be involved.  So it can't look up a per-axis quantity.
This wasn't working reliably in earlier versions either, which was
part of the reason for adding the second parameter.

Since the per-axis timeformat was not reliable and was never
documented anyhow (perhaps for that reason?), I don't feel badly about
failing to provide a 100% backwards-compatible replacement.

I have a patch to provide backwards compatibility for the common case:

   plot <foo> using (timecolumn(N)):M

It does not catch more complicated cases in which the timecolumn()
call is part of a longer expression, as in

   plot <foo> using (Offset_2_weeks + timecolumn(N)):M

I don't see a way to catch that without adding additional bookkeeping
code to the expression parsing.  That might be worth looking into
at some point, but right now it would be a major distraction.

	Ethan