Saving as .fig changes dateticks and grid spacing

I have two sets of data providing temperature information for a specific day.

Exporting the resulting figure as a .png works fine, but exporting as .fig (File -> Save As) and re-opening that file causes visual changes along the x-axis. (Matlab R2015a)

My code:

% Read first dataset
% [SNIP]

% Manually enter day
time_days = input('What day? \n');

% Plot first line
figure(1)
plot(time1,Tair)
xlabel('Date & Time')
ylabel('T_{air} (°C)')
title('Air temperature')
grid on

% Import second dataset
% [SNIP]

% Plot second line
figure(1)
hold on
plot(time2,T_airRR)
xlim(datenum([dateshift(time2(1),'start','month')+days(time_days-1)+hours(6)-minutes(1) dateshift(time2(1),'start','month')+days(time_days)-hours(2)+minutes(1)]))
legend('Ship','Base')

The second dataset covers the entire month even though I plot only one day of the data, hence the xlim construction. It jumps back to the beginning of the month, then forward to the correct day, and then adds/subtracts hours so that the data shown is from 05:59 to 22:01. time1 and time2 are both datetime arrays.

Running this yields the LEFT figure. Saving as .fig and re-opening yields the RIGHT figure.

Clearly, the x-axis is broken, because the data cursor still provides correct values. Also, panning or zooming in resets the axis, 'fixing' it.

What's going on here, how can I prevent it?

[DrewVam55]

I am not exactly sure what is happening here, but I would suggest looking at http://www.mathworks.com/matlabcentral/fileexchange/27075-intelligent-dynamic-date-ticks for help with date/time axes.

[David Barry]

Certainly doesn't sound right! Can you upload some example data so we can run your example? I would also recommend contacting MathWorks technical support.

Answer 1

[Walter Roberson]

Please check out https://www.mathworks.com/support/bugreports/1246428 and see if the workaround solves your problem.

[SvB]

It hadn't occured to me this might be a bug rather than some subtle mistake by me. This is indeed the exact problem and the workaround functions as described (had already figured that out, fortunately). Good to see it's fixed in newer versions.

For now, I'll just have to remember to pan/zoom before reading data :)

[Peter Perkins]

SvB, it's also worth noting that if you can upgrade to R2016b, you can set the axis limits (and similar things) with datetime values, without having to call datenum:

xlim([dateshift(time2(1),'start','month')+days(time_days-1)+hours(6)-minutes(1) dateshift(time2(1),'start','month')+days(time_days)-hours(2)+minutes(1)])

Also, when working with datetimes that don't have a timezone set, you're save using days, but if you start using timezones, you're going to want to use caldays to account for DST shifts. Using caldays even without timezones won't hurt.