ansemjo
Time written as xlabel is misleading
The time written in the csv file is in the following format:
2025-02-18T11:07:01.958973Z
On the generated svg file, the x-axise goes from $SOMEWHEN_IN_THE_PAST to 2025-02-18\n11:15:00, and it seems as if the measurement was taken at 2025-02-18T11:20:18.
Unfortunately my actual (local) time when speedtest-cli is executed was at 12:20:18
The Gnuplot script also prints when the graphics is plotted, in this case: plotted 2025-02-18 12:07:23 CET.
Is there any chance to have gnuplot convert the x-axis to CET too?
The timestamps in the CSV are always stored as UTC, hence the Z at the end. I believe that's what the TZ variable was for, to adjust the timezone during rendering. Not sure where exactly in the CET timezone you live but you could try adding TZ=Europe/Berlin to your config.
I'm executing the gnuplot -c plotscript "manually", and I overlooked it in the readme that you set the TZ env variable in your docker command or when executing plotscript directly.
But I just tested it out; it does not seem to make a difference.
The output of speedtest-cli is unaffected by TZ, and plotscript does not take it into account.
I see that speedtest-plotter uses TZ internally; I'm thus confident that using speedtest-plotter provides a consistent experience.
It would be a nice enhancement if plotscript could work with the csv output of speedtest-cli directly.
Aha, I see! Well, there's a couple of problems:
- As far as I can tell,
speedtest-clionly ever outputs timestamps in UTC with aZat the end. There are pull requests to make it use local time but that tool is not maintained anymore, anyway. - Gnuplot itself always assumes timestamps in UTC and has "no provisions to change time zone". No idea why it behaves differently for the plot timestamp and the axis labels, though.
You could use a hack like this, to add an appropriate amount of seconds to the time column in your data. Though that doesn't account for daylight savings either. To do it properly, you'd need to use a script to pre-format the timestamps in your desired timezone – so, exactly what speedtest-plotter is doing. ;)
It won't "fix" the timestamp but you could also add %Z to the xtics format to at least make it apparent that it's showing UTC times (in theory, haven't tested this):
set xtics format "%Y-%m-%d\n%H:%M:%S %Z" out
I see
set xtics format "%Y-%m-%d\n%H:%M:%S %Z" out
does not seem to work, I guess the easiest way is to adapt the csv file then, the suggested workaround, as you mentioned, does not work well with daylight savings.
No idea why it behaves differently for the plot timestamp and the axis labels, though.
Yeah, that was the most confusing part in my setup; I thought my cron job was not running at the correct time until I saw that timestamp.
@ansemjo I think you can close the issue, as far as I can see there is nothing to do.
FYI, I just found librespeed-cli(https://github.com/librespeed/speedtest-cli, has the same CLI api of the original speedtest-cli and is already packaged in some distros).
Unfortunately the csv columns are ordered differently, but with it I have no inconsistencies with the timestamps.
It is just a matter of adapting ARG1 using <N> in the plot script.