[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Plotting a table of date+time pairs
From: |
Michael Heerdegen |
Subject: |
Re: Plotting a table of date+time pairs |
Date: |
Wed, 04 Dec 2024 11:50:40 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
"Fraga, Eric" <e.fraga@ucl.ac.uk> writes:
> > I now have one remaining problem: my time values in the second column
> > contain the name of the time zone - the purpose is to flag the time as
> > summer or winter time. Currently I need to remove these indicators from
> > the table, else plotting fail, gnuplot doesn't understand the data.
>
> You can specify the format of dates/times in gnuplot and then manipulate
> them. See "time/date specifiers" in the gnuplot info manual and also
> read about the strptime() function. I don't have any examples of these
> at hand unfortunately.
Yes thanks - but I really think Org gets it wrong. Look:
With
| plot data using 1:(timecolumn(2,"%H:%M") ...
gnuplot happily accepts a data file looking like
| 2024-09-18 11:40 CEST
| 2024-09-19 11:27 CEST
| ... ...
It just discards the timezone which is good enough. No problem with the
kind of data for gnuplot (AFAIR I read in the gnuplot manual that time
zones are not supported ad-hoc - anyway, I don't need this for
plotting.)
But the real problem is that the org table export mechanism thinks that
the time field doesn't look like a numerical field, so it wraps every
such field in quotes, and the exported data file will look like
| 2024-09-18 "11:40 CEST"
| 2024-09-19 "11:27 CEST"
| ... ...
instead. Then gnuplot doesn't find data matching "%H:%M in the second
column of the data file and interprets it as zero or 00:00am or
whatever.
Can I make gnuplot disregard the quotation marks? Else I must tell org
that these fields should not be quoted. But ironically the only way I
know to do this is again a hack: I must adjust
`org-table-number-regexp' which... sounds like a good solution but since
org disregards a file local binding I must change the global binding of
the variable! Ugh. Better solutions welcome.
Thanks,
Michael.