pgfplots may have trouble with small datetime ranges on an axis

[erikhuizinga]

trafficstars

If the limits of an axis are small, then pgfplots may have trouble with the axis limits, adjusts them (bad, bad boy pgfplots!) and issues a warning:

Package pgfplots Warning: Axis range for axis [x | y | z] is approximately empty; enlarging it (it is [[newMin]:[newMax]]) on input line [lineNumber].

For example, try the following and see the LaTeX output below.

x = datetime(2017, 1, 1) + seconds(0:10);
y = 0:10;
figure
plot(x, y)
matlab2tikz m2t.tex

Note the x axis labels are incorrectly put on top of each other, because pgfplots has changes the x axis limits. This is caused by the conversion of datetime data to double through the datenum() function. This results in very large date numbers (more or less the number of days since the year 0), but the axis limits range is relatively small. Compare:

data = datenum(datetime(2017, 1, 1) + seconds(0:1));
data(1), range(data)

If you run this code, you can see in the output that the difference in order of magnitude between the data and its range is about 10^10, which apparently is too much for pgfplots to handle.

This can be solved by subtracting the relatively large offset from the date numbers.

[okomarov]

The simple workaround is to strip the whole part in the datenum, i.e. with rem() or mod(), before you plot.

You clearly do not need the integer parts since your plot zooms in at the seconds level.

[erikhuizinga]

Do you mean x = mod(x, 1);?

It seems true what you say, but it isn't. It does not work for plots with axis limits that are more than one day beyond the data on that axis. For example:

x = datetime(2017,1,5) + hours(0:10);
y = 0:10;
plot(x, y)
xlim(datetime(2017, 1, [1 10]))

Then simply removing the whole part from the axes limits and the data in x would ignore the fact that the axes span multiple days and also would ignore that the data can span zero or more days. The data may start on a different day than the axes limits.

Therefore, I have implemented the calculation of one global amount to shift in #971, which then is communicated through the axes options to the relevant parts of matlab2tikz. This way, every datetime to date number conversion can subtract the same shift, which is essential. It's not a neat solution and if you think a better solution is necessary, please adjust my code.

[okomarov]

Now I recall the full workaround: https://github.com/matlab2tikz/matlab2tikz/wiki/FAQ#user-content-time-series-plot-raises-dimension-too-large-tex-error

[erikhuizinga]

That's a workaround to be used by the user and it's for the deprecated date numbers and date strings, which are difficult to use if you already use the more recently introduced datetime type.

I agree with what you said in #971: this may not be a problem for many. However, as time passes, more and more people will use datetimes instead of the old time and date types. Therefore, I still think it's a good idea to support the datetime data type (based on) the way I did in the PR.

[youcann]

I have the same problem using time= datetime(time, 'inputformat','dd-MMM-yyyy HH:mm:ss.SS', 'Format','HH:mm:ss'); to get time strings from a csv.

Can you suggest an alternative? Or what do you mean by 'more and more people will use datetimes'?

[erikhuizinga]

This issue is 4 years old. Back then the datetime type was only 2 years old (introduced in version R2014b). Therefore I said that it would be used by an increasing number of people over time, because this new type was meant to replace existing date and time types that have limitations.