[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 #10 from Nicolas Brisset <nicolas brisset eurocopter com>  2012-02-24 22:44:22 ---
Hopefully the added part of the dialog is straightforward enough that everybody
understands it. The idea is to ask for:
- the name of the time vector and its formatting
- the name of the date vector (if separate) and its formatting
- the offset to add to the first data line in case the format is not complete
(e.g. does not contain the day or the year and the user wants to have it
displayed)

Some more explanations and comments:
1) The time options are as follows (for b and c the lineedit should be
disabled, otherwise enabled): 
   a) Index, step in s: [value in the lineedit] => use the line number (index)
as time, with a fixed delta of x seconds between two lines (with the initial
value being the first line offset + the first value)
   b) C Time (int) => interpret the values in the time vector as an integer
corresponding to the number of seconds since Jan. 1st 1970, aka the Epoch
   c) Seconds => interpret the values in the time vector as seconds (to add to
the first line offset, if provided)
   d) ASCII, format: [format in the lineedit] => transform the ASCII strings
found in the column of the time vector using the format template provided by
the user. Should be easy to do using QDateTime::fromString()
2) Date options are as follows (lineedit enabled for both):
   a) Index, step in days: [value in the lineedit] => use the line number
(index) as day, with a fixed delta of x days between two lines and the initial
value being the first line offset + the first value
   b) ASCII, format: [format in the lineedit] => transform the ASCII strings
found in the column of the time vector using the format template provided by
the user.
3) As discussed above, when both time and date are specified they should be
merged into a single vector. We can discuss how to call it, maybe something
like "DateTime" or "Date+Time"?
4) If there is no vector for time or date or the user is lazy it should be OK
to not select anything, then we would have the current behavior
5) When you change the format options, especially the line from which to read
field names, the comboboxes to select time/date vectors should update.
Otherwise the only way is to click "Apply as default" at the bottom, close the
dialog and reopen it to finish. I doubt many users will have the idea to do
that...
6) We may have to validate the values in the lineedits before parsing the data,
especially as they should be either numbers or date/time strings according to
the selected options and not all values are acceptable. The initial contents
(hhmmss.zzz in my example) should change to reflect the kind of value expected,
or be empty to avoid creating confusion. I don't know how difficult it is to
provide a behavior with an initial value which disappears as you start typing.
Possibly a tooltip is good enough and much less effort
7) If time and date are in a single string (like YYYYMMDD-HHMMSS.SSS) the user
should select only the first checkbox. Maybe the current labelling does not
reflect that very well
8) The third option does not make sense if there is not at least one of the
first two
9) If at least one of the first two options is used then Kst should activate
automatically the "interpret as time" feature of the X axis: the corresponding
vector should have a flag set somewhere saying it is a time vector

Well, this sounds like quite some code to write, but judging by the number of
mails we see on the list requesting that I think the feature is really worth
it.

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