graph bugs - wrong labels and grid/tick marks

[aleqx]

Consider the CSV data below. Note how the first entry is close to 00:00 UTC (01:00 UTC+1) on 30 Sept and the last entry is close to 12:30 UTC (13:30 UTC+1) on 7 Oct. Screenshot below. Also included reference (correct) plot of the same data underneath.

It seems your plot takes the date range, and divides that into a fixed 10 segments, and then places tick marks (vertigal grid lines) at values which are NOT multiples of 24h ... which makes it look wrong when interpretting the graph (*). It would really be better to make sure tick marks are at day boundaries for the graph to make good sense. If your limit is max 10 grid segments, then if the date range is N days, then place grid lines every k days where k=ceil(N/10), where the first and last grid segments would be smaller than 24h, which is fine.

(*) Visual bugs:

• it shows some labels twice, e.g. 30/09, 03/10, 06/10, which is confusing.
• the vertical grid lines (tick marks) are expected at day boundaries (00:00) in order for the graph to make easy sense, but they are at an unknown value which is not a multiple of 24h. Compare them with the tick grid lines from the reference plot underneath.
• it shows the last tick mark (vertical grid line) of 07/10 at the same x location as the last entry. But the data entry x value is 13:30. This makes it look as the data was collected at either the end of 07/10 or the start of 07/10 ... both are wrong, but even if it were true, it would look ambiguous.

FeatureName,Timestamp,Value,Note
UA,2023-09-30T00:58:00.000+01:00,4.6,
UA,2023-09-30T01:19:00.000+01:00,5.7,
UA,2023-09-30T01:23:00.000+01:00,5.5,
UA,2023-09-30T01:35:00.000+01:00,5.8,
UA,2023-09-30T02:13:00.000+01:00,5.4,
UA,2023-09-30T13:16:00.000+01:00,4.6,
UA,2023-09-30T13:19:00.000+01:00,3.6,
UA,2023-09-30T13:22:00.000+01:00,3.3,
UA,2023-09-30T13:30:00.000+01:00,4.8,
UA,2023-09-30T13:33:00.000+01:00,3.7,
UA,2023-10-01T13:04:00.000+01:00,4.5,
UA,2023-10-01T13:06:00.000+01:00,4.4,
UA,2023-10-01T13:07:00.000+01:00,4.2,
UA,2023-10-01T22:53:00.000+01:00,5,
UA,2023-10-01T22:54:00.000+01:00,5.1,
UA,2023-10-01T22:55:00.000+01:00,5,
UA,2023-10-01T22:57:12.000+01:00,5.1,
UA,2023-10-02T13:36:44.000+01:00,4,
UA,2023-10-02T13:38:21.000+01:00,5,
UA,2023-10-03T13:40:00.000+01:00,4.7,
UA,2023-10-03T13:41:00.000+01:00,3.7,
UA,2023-10-04T13:38:14.000+01:00,5.2,
UA,2023-10-04T13:39:46.000+01:00,4.8,
UA,2023-10-04T13:40:44.000+01:00,3.1,
UA,2023-10-05T18:56:54.000+01:00,4.4,
UA,2023-10-07T13:15:44.000+01:00,5.6,
UA,2023-10-07T13:16:31.000+01:00,5.3,
UA,2023-10-07T13:30:13.000+01:00,4.9,

[SamAmco]

Hi. You are correct that the graphs just divide the time into 10 segments and calculates the date at each of those points. This definitely needs improving. It needs to be a little more broad than your suggestion there just because it should adapt to whether the range is best represented in blocks of minutes, hours, days, months etc. But yes this needs doing really.

[aleqx]

My suggestion was only an example. You'd use whatever scale the data span has (days, hours, minutes, etc).