[BUG] Scaling of time axes on bar charts

[tomkcook]

See this example.

Expected behaviour

The first data label is the same time as options.scales.xAxes[0].time.min, so the first bar should be at the very left side of the chart (the axis itself is drawn correctly with the tick mark at this point).

Current behaviour

There is a wide gap (approx. 1/4 of the width of the chart) between the tick denoting midnight, 24 July 2017, and the bar with that label. Note that the width of this gap depends on how much of the x-axis domain the labels on the data fill; if you extend the dataset in the example so that it covers the whole of the domain set by min and max, the gap is barely noticeable.

Possible Solution

I don't know of any.

Steps to Reproduce (for bugs)

See the pen linked above.

Context

I'm trying to plot a timeseries and for obscure reasons, the field I'm doing it in normally uses bars to represent them, not line charts. I'm trying to present a week of data at a time, with the scale of the X axis remaining the same even if I only have a few hours of data for that week.

Environment

• Chart.js version: 2.6.0
• Browser name and version: Chrome 59.0.3071.86 (Official Build) (64-bit) on Ubuntu 17.04
• Link to your project: Nothing online as yet.

[etimberg]

This should be fixed already in master. @simonbrunel and @benmccann have the details

[benmccann]

I don't totally understand what you're saying you expect to have happen. However, there was a recently introduced mode:series in the time scale in master that you'll probably want to use if you're trying to plot a time series chart. Can you try it and see if it fixes your problem?

[simonbrunel]

@tomkcook is https://codepen.io/anon/pen/RZNvqJ better?

I think that's a dup of #4562

[tomkcook]

@simonbrunel I guess it's better, but still not right. Perhaps this demonstrates the problem more clearly: https://codepen.io/tomkcook/pen/KvpwWZ. All the labels are times on 24 August, but the bars clearly spill over into 25 August.

@benmccann I don't think 'mode:series' helps. I definitely want a linear x axis.

I'm fairly sure this happens because I'm explicitly setting the bar thickness (options.scales.xAxes[0].barThickness: 20) but src/controllers/controller.bar.js:242 doesn't update fullBarSize to match the explicitly set thickness; this is what #4561 addresses.

[mMerlin]

SUMMARY:
Looks like 2 problems. 1 is different time zones for the data labels and the ticks. The other is where the position of the bar is relative to the time axis.

I reproduced the starting PEN example as a jsfiddle to play with. It seems that if/when the xAxes is specified as time type for a bar chart, the relationship between the data point labels and time is rather vague. Starting from the clone, I adjusted the first label date. 2017,7,23,0 shows just fine, but still well past were the time axis says the 24th should be. In fact it looks right at the end of the tick text for the 24th. Changing the date to 2017,7,22,23 causes the time axes tick to rotate about 45°, the first tick is still the 24th, and the bar is still visible after the 24th. The earliest time still visible is 2017,7,22,21. 20 hours looks to be right on the vertical axis.

Changing the last label instead, going from 2017,7,26,0 to 1 hour later adds a tick label and grid line for Aug 26, that is well before final bar. Going from 2017,7,28,0 to 1 hour later, and 2017,7,30,0 to 1 hour later, adds a tick label and grid line for Aug 28 and Aug 30. Again well offset from the actual bar. The latest label where the bar is still visible is 2017,7,30,7, which is almost on the Aug 31 (final) grid line. Changing only the final date label does not cause the ticks to rotate.

Going a different way, I changed the original chartjs version to a build of f16d8a3 that I was using for something else. That started with ticks every 2 days from Aug 24, ending with Sep, due to the code changes for major/minor time ticks. Adjusting the dates for the first and last labels again, the earliest I could still visually see, was 2017,7,23,6. The latest, 2017,7,31,4. Which correspond close to the start and end grid lines. No tick rotation jumps with any of that. With this version, these settings, I am seeing about an 18 to 20 hour offset between the tick labels and the time axes ticks. That changes when I set the unit to hour, and reduce the time maximum.

Changing , or removing the barThickness did not seem to adjust the position of the bars, though it did only add to one (the lower) side. It looks like the origin (placement) point for a bar is at the far (higher) end, but the label point is at the start. Removing the barThickness setting, to let chartjs pick a default, got the start of the first bar a lot closer to the Aug 24 tick label and y axis. Now (with the f16d8a3 build), 2017,7,23,19 looks to touch the Y axis.

I don't know if this is involved, but my time zone is GMT-0600. Could part of the problem be date to text to date conversions, mixed with time zones? Hover is explicitly showing me times in GMT-0600 corresponding to the data labels. IE Hover for the second bar shows
Thu Aug 24 01:00:00 GMT-0600 (MDT) # of Votes: 200
I can not directly see what time zone is in use for the ticks, but the test above with no barThickness looks VERY close to a 6 hour offset.

[tomkcook]

FYI I am in the UK, so my current timezone is BST (UTC+1).

[mMerlin]

Maybe I was not explicit enough. IF the local (browser) time zone is a factor (not just the time zone set for the web server), then what each of us see for a single live fiddle (or other) could be different. I was explicitly taking advantage of that for one set of charts I worked on, to show the tooltip times in the users own timezone, while storing all the data in GMT.

Someone in a different timezone might, or might not, be able to replicate what I did, using the same numbers (date/times) I used. If the same results are seen everywhere, then the local time zone can be crossed off as a likely source of the issue seen.