Dates are squished to the left for graphs

[desa]

[TCL735]

Might be the same issue as influxdata/giraffe#135

We will keep both for now and ensure they are resolved together.

[TCL735]

giraffe uses d3 to determine the number of time ticks. d3 takes a suggestion on the number of ticks desired but will often ignore the suggestion and return the number of ticks based on its own algorithm.

giraffe's estimate of the number of ticks is very conservative, using the width of 'W' for the average width of a character. This leads to many cases where giraffe is underestimating the amount of available space on the axis.

In a battle of wills, giraffe truncates the array of time ticks when d3's length is longer than its own estimate. But d3 has already scaled the axis, leading to empty space at the end of the axis.

Short of giving the user control over the number of time ticks on the x-axis, giraffe should not override d3's algorithm. The simple fix is simply to remove the if-block at https://github.com/influxdata/giraffe/blob/master/giraffe/src/utils/getTicks.ts#L45

[TCL735]

There is one case where it is appropriate to override d3. When the actual length of the time tick label is longer than what d3.scaleUtc would create, such as this one:

dddd, MMMM D, YYYY HH:mm:ss

which is another way of saying for example: Friday, January 3, 2020 17:07:18

d3 would overlap these labels making them unreadable.

Edit: After further analysis, overriding d3 here would again lead to empty space at the end of the axis. d3 has additional functionality to allow for scaling the axis based on a specified interval. Doing this to space long labels evenly is beyond the scope of this issue. Customized scaling of the time axis should be left as a future enhancement. As such, the above label format will be removed.

Edit 2: We don't override. We call d3 with different numbers until the total number of ticks fits onto the x-axis. This will maximize the usage of the x-axis as per d3's algorithm.