[Kst] 2.0.7

[Nicolas Brisset]

> I like your suggestions for time, but some of them make take some
> more thinking, so I don't think we should hold up a bug fix release
> for them. Svn is in far better shape than 2.0.6, so we should
> release.
Well, I know. Release early, release often....
But I must say I'm a bit frustrated if we release as is. A minimal change would have a dramatic impact. 
Let me give you a concrete example to try and convince you to do one more bit. 
I have lots of files with time as a column of the form (see example in sample_data/ascii_time_date_2.txt and try to reproduce):
125500.050
125500.100
125500.150
125500.200
125500.250
125500.300
125500.350
125500.400
With the current svn status and thanks to Peter's excellent work, I can read that column as a time/date vector using formatted time. Then I get plots where the x axis is made of some seemingly random real values where no user would recognize C time spontaneously!
To set the x axis correctly in all plots, I can fortunately use the edit multiple approach but I still have to set all x axes to "Interpret as C time", display as QDateTime format string and omit the date part (no yMd symbols, since they're completely wrong!). It's not very user-friendly, if usable at all. And the worst is that even if you understand what's going on you have no easy way of getting correct dates.

In my opinion, we're so close to a much better solution that we should do the following minimal effort (there is much more that can be done for a great support of time-based access, but I agree that this will have to wait):
1) add an offset field taken either from a QDateTime formatted string of from the file's date so that the date is not set to January 1st 1970 if not given
2) add an option to interpret INDEX as a time index, in which case we'd compute it as C time based on the offset and a fixed sampling interval.
3) arrange for the data wizard to create the plots with an appropriate x axis setting if using the time options
Thinking a bit more about it, I realize it's not that easy for the wizard to get the information on whether/how time is to be interpreted. So I agree that 3) may be too much for 2.0.7. But we should at least implement 1) to have correct data at all, and hopefully also 2) which sounds like fairly easy and which would allow reading Labview files, which a lot of people are waiting for.

> Nicolas: when do you think you will be able to poke at it for
> regressions?
I'll do some tests now while you think about my points above... I'll let you know if I find something. 
And please let me know whether I was convincing enough. Sorry for insisting, but I think it's really worth the extra pain!

Nicolas