#2399 Wrong ticks drawn in timedate format

[Anonymous]

This may be reproduced on v5.2.8 (windows) with

set xdata time
set timefmt "%Y-%m-%d"
set format x "%m/%d"
set autoscale noextend
set term pngcairo size 2000,400
set output "cal.png"
$data << EOD
2020-03-28 0
2021-01-13 1
EOD
plot $data using 1:2 w l

Note that the right edge is 01-13, and the preceding minor ticks are at 01-01 and 01-11 (as one can check with set mouse label "right point ps 1" and mid-clicking). However, the distance between the ticks is 66 pixels (≈6.6 pixels per day), and the distance between the right tick and the right edge is 8 pixels (instead of the expected ≈13 pixels).

Note that even with the default size of PNG output the error is much more than what may be explained by rounding. (Same effect in wxt terminal.)

---

Ilya Zakharevich nospam-abuse@ilyaz.org

[Ethan Merritt]

Could you clarify why you are expecting any particular number of pixels here?

The automatic choice of mxtics seems to have picked set mxtics 3. I don't know why that number in particular, but honestly I don't think there is any number of evenly-spaced minor tics that makes sense for a time plot where the major tics are in one month intervals. Months don't have equal numbers of days. Perhaps the program would do better to disable mxtics by default for time data.

If you tell gnuplot set mouse mouseformat 3 it will track the mouse position in time coordinates so you can get pretty accurate feedback of where the ticmarks or other plot features are. To me everything looks correct.

If you want ticmarks at exactly one week intervals you could say:

     unset mxtics
     set xtics 3600.*24.*7.     # Number of seconds per week

Does that help?

[Ethan Merritt]

I see no bug here, although arguably it is a bad idea to allow the user to draw minor tics for an axis where the major tics are months. The minor tics are placed at some exact fraction of the spacing between major tics, but this will not come out evenly at the start of a day. So the tics that you are measuring between are not an even number of days and you cannot derive a pixels-per-day value by doing this.