[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 #13 from Nicolas Brisset <nicolas brisset eurocopter com>  2012-02-26 22:52:28 ---
(In reply to comment #12)
> How do you specify that columns 1 and 2 form a time/date, and what format they
> are in?
If you have time in column 1 and date in column 2, you check the two boxes and
indicate the format for each. Checking the 2 boxes should automatically create
a datetime vector and if possible preselect it for the x vector in the
datawizard. As discussed above, it the 2 are required they should be merged.

> How do I specify that line 5 contains a time offset and that line 7 contains a
> dT?
For now, I think manually is enough. You can see the header in the preview
pane, just copying the values should be OK.

> What is the purpose of Date and Time separately?   kst plots do not currently
> support time of day (but not date) output.  This could be changed if we really
> need it.  But I can't see a use for date only.
I'm not sure I understand your comment. But regarding date only: image
meteorological data with amount of rain per day, or a number of downloads per
day (e.g Kst downloads, to visualize the very good trend :-))
In case we have date only, I think using a QDateTime object to convert to a C
time internally as currently support would be good enough.

> So: datetime and time, with datetime being the most likely scenario.  We could
> ignore time for now I think.
I don't understand this one...

> Basically, there are three types of datetimes in data sources:
>  (a) datetime as a numerical value, like JD or ctime in a vector: 
>      already supported
>  (b) calculable datetime (requires T0, dT, and an index vector)
>      these could be manually entered, or could be metadata in the file.
>  (c) ASCII specified date as column(s) in the file.  
>      There are a number of common formats, and many more uncommon ones.
> 
> We should be able to support all three.
Agreed, and I think my proposal does just that.

> (b) types could benefit from scalars in ascii files.
Correct. One thing we may try in when parsing the header, instead of just
creating string metadata: if the lines follow the pattern [sequence of
letters]: [number] then create a scalar instead of a string. But I see no easy
way to enter that in the same dialog. As mentioned above, I think copying
manually is acceptable for that.

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