Re: [Gnuplot-info] relative second time data

[Ethan A M. <eam...@gm...>]

On Wednesday, 21 October 2015 11:44:30 PM Tait wrote:
> > > ---------------------------
> > > set xdata time
> > > set timefmt "%s"
> > >
> > > plot "-" using 1:2 with lp
> > > 0       0.0
> > > 1       0.5
> > > 2       1.0
> > > 3       1.5
> > > EOF
> > > ---------------------------
> > 
> > ...
> > This answer is for gnuplot version 5.
> > ...
> > 2) If  the input  is time-in-seconds but the output is some clock time
> > (hours:minutes:seconds) then you want the following.  Notice there is
> > no "set xdata time".
> > 
> > set xtics time format "%H:%M:%S"
> > plot '-' using 1:2 with lp
> 
> There's nothing special about 0, 1, 2, 3... it could just as well be
>   1445469700 0.0
>   1445469701 0.5
>   1445469702 1.0
>   1445469703 1.5

I agree there is some sort of bug with "%s".
Right now I have no idea what the issue is, but since the same
behaviour is observed in version 4.6.4 it is a bug that has
been around for at least a couple of years.
I notice that if you put decimal points after the values in the
first data column then the bug isn't triggered. 

But the larger point is that the commands that are triggering the
bug are not necessary in the first place.  If you are reading in
raw seconds you do not need a time format.

> Does this mean "set xdata time" is deprecated? 

It is no longer necessary for most purposes, but so far as I know
it still works as it did since gnuplot version 4.6.4 
(I am seeing different output from gnuplot 4.6.3).

> Or only deprecated
> for the "%s" timefmt? I'm not sure I see why "timefmt '%s'" works
> without "set xdata", or "set xdata" works with e.g. "timefmt '%S'",
> but the particular combination of xdata and %s breaks. And I'm not
> sure it will be clear to other or new users, either. There must be
> some principle behind the behavior being what it is, but I don't
> see it. Can you explain more?

I'll try. 

Why the old commands were insufficient
======================================
- The time format present in a data file is a property of that file,
not of some gnuplot axis.  So having a global command like 
"set timefmt" is useless if you want to read from two files with
different formats.  
- Requiring time to be associated with a  particular output axis
(e.g. "set xdata time") does not work if you are trying to read
a time for some purpose other than an axis coordinate.
What if you want to plot something like
   plot DAT using 1 : (time_in_column(3) > time_in_column(4) ? N : -N)
The time values in question are neither x data nor y data.
- Relative time values basically didn't work.  Negative numbers were
interpreted as some date prior to 1-Jan-1970 rather than as a value in 
seconds relative to time 0. Wrapping (e.g. seconds never exceed 60,
hours never exceed 24, etc) may be undesirable.

The version 5 syntax
====================
The preferred way to read time data on input is like this:
  fmt3 = "%m/%d/%y"
  fmt4 = "%Y %M %d"
  plot DATA using 1 : (timecolumn(3,fmt3) > timecolumn(4,fmt4) ? N : -N)
This does not require that either the x or y axis is being
used for time data, and allows different time formats for each column
in each file if needed.  For convenience if you omit the 2nd parameter
to timecolumn() it will default to the current value of "set timefmt"
  set timefmt "%H:%M:%S"
  plot DATA using 1 : (timecolumn(3) > timecolumn(4) ? foo : baz)
The deprecated "set xdata" command is not relevant in either case.

The preferred way to set an output format is like this:
  set ytics time format "%H:%M:%S"
Again the deprecated "set xdata" command is not relevant.
The y value may come from a file, they may be calculated, or
whatever.  This just sets an output format.

Version 5 also supports relative times (e.g. "%tH" format),
and geographic coordinates "set xtics geo format "%D:%M:%S" 
for degrees/minutes/seconds wrapping at 360° rather than 24 hours
and recognizing E/W formats for +/- values.
Maybe some other stuff I'm not recalling at the moment.


Backwards compatibility
=======================
As you know, we always try to retain backwards compatibility 
as much as possible.  The intent was that the older time
commands like "set xdata time" still work, at least to the
extent they ever did.

	Ethan