[Kst] [Bug 243684] Handling of formatted timestamps as a valid field in input files

[Nicolas Brisset]

https://bugs.kde.org/show_bug.cgi?id=243684





--- Comment #2 from Nicolas Brisset <nicolas brisset eurocopter com>  2011-12-04 12:06:52 ---
For this feature we'll need to update:
1) the GUI (ASCII config dialog)
2) the backend code which takes care of reading the data and providing it to
kst core

Copying from the message I sent to the list yesterday, here are my current
thoughts:
1) GUI:
there we have to ask the user for the minimal input we can't guess. It is a bit
tricky since I'd like to support both cases where date and time are together
(YYYYMMDD-HHMMSS.SSS, I have such files!) and where they are in 2 vectors (e.g.
YYYYMMDD and HHMMSS.SSS in 2 separate vectors). The idea would be to allow
having one column which contains time and possibly date, and another optional
one in case we have a separate column for the date. Since the drawing code
probably considers only one X vector, we would need to merge the two in case
they are separate. So in the end we'll receive from the config dialog in the
_config member the following options:
   a. (bool) ASCII-formatted time/date
   b. (QString) name of the time/date vector
   c. (QString) format string of the time/date vector, e.g. HH:MM:SS or
YYYYMMDD-HHMMSS.SSS
   d. (QString) Meaning of 0, i.e. if 000000.000 in the file actually means
20111203-120000.000 in reality because the experiment started today at noon,
then must have a way to let kst know it (I think that was also Matt's request
recently)
   e. (bool) Merge separate ASCII-formatted date
   f. (QString) name of the date vector
   g. (QString) format string of the date vector, e.g. YYYYMMDD

2) backend code: in a first step until we have clarified the way we transfer
date/time vectors from the datasources to kst core, I'd create internally an
array of QDateTime elements based on the provided config options, which we'd
return in the double * pointer in readField() when reading the time/date vector
indicated in the config dialog. We may have to cast to ints representing the
Unix time (time_t type). It is ugly, but we can adapt it later easily, and it
should work for at least some formats. Barth, as soon as you know better be
sure to let us know. Maybe there is already more appropriate support for time
vectors but I'm not familiar with it. One interesting question there could be
whether we should cache the time data and construct it directly when parsing
the file, to avoid having to manipulate QDateTime objects continuously, which
may be heavy. Peter, do you have an opinion on that?

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.