Different values of datnumber for same date-time?

When I convert given date-number '2011-01-06 0:45' by

datenum(2011-01-06 0:45,'yyyy-mm-dd HH:MM')

I get

734509.0313

as date-number.

But When I generate a vector of date-numbers using

    begin_date_time=datenum('2011-01-06 00:00:00','yyyy-mm-dd HH:MM:SS');
    str_next_date=strcat('2011-01-06',32,'00:',time_scale{ind_node},':00');
    next_date_time=datenum(str_next_date,'yyyy-mm-dd HH:MM:SS');
    interval=next_date_time-begin_date_time;
    end_date_time=datenum('2011-12-31 00:00:00','yyyy-mm-dd HH:MM:SS');
    full_data_time_steps=begin_date_time:interval:end_date_time;

The fourth date-number in the vector 'full_data_time_steps' is

734509.0312.

But it corresponds to the same date-time '2011-01-06 0:45'. I am not sure why this is happening and how to solve this? Any help is appreciated.

Answer 1

[dpb]

It's the result of floating point rounding in the two different ways you generated the datenum values --

In

full_data_time_steps=begin_date_time:interval:end_date_time;

the interval value is an approximation and over the vector it will accumulate noticeable differences.

The solution is to always use integer values of whatever granularity is needed to generate sequences of dates such that the internal calculations are reproducible.

Presuming you're using ML release R2014b or later use datetime instead of datenum; there are many features that make it more flexible.

[Abhinav]

I don't understand the part 'The solution is to always use integer values of whatever granularity is needed to generate sequences of dates such that the internal calculations are reproducible'.

Also, I am using MATLAB 2014a.

[dpb]

You didn't provide time_scale for absolute certainty but it appears your delta would have been 15 minutes if my old eyes are reading correctly...whether it's that or some other value specifically isn't critical; it's the technique that matters so I'll illustrate on that basis.

One way to prevent roundoff would be

>> dv=datevec(datenum('2011-01-06 00:00:00','yyyy-mm-dd HH:MM:SS'));     % get the date vector corresponding to your start
>> interval=15; % set an interval, we'll assume minutes
>> dn=datenum(dv(1),dv(2),dv(3),dv(4), [0:interval:60].', 00); % generate a sequence of an hour at that interval
>> datestr(dn)  % see what we got
ans =
  5×20 char array
    '06-Jan-2011 00:00:00'
    '06-Jan-2011 00:15:00'
    '06-Jan-2011 00:30:00'
    '06-Jan-2011 00:45:00'
    '06-Jan-2011 01:00:00'
>>

NB: datenum will "roll over" the minutes field to the next level of granularity; the last time is 01:00:00 rather than 00:60:00 as expected. This works for all fields and propagates up to the higher-levels correctly including accounting for days in month, leap years, etc., etc., etc. And, since the interval is in integer minutes, there's no rounding in that interval and so the end result is that the rounding to store the final result as a double occurs identically the same way as when converted from the precise date string.

The computed result above matches:

>> dn(4)==datenum('2011-01-06 00:45:00','yyyy-mm-dd HH:MM:SS')
ans =
  logical
   1
>>

I hardcoded the upper limit; that can be computed from the desired end date and the number of intervals required computed.

One can see the same issue if one uses linspace() or colon in computing a vector of doubles and comparing results.

[Abhinav]

Thanks a lot for the great answer!

[dpb]

No problem; it's a very common issue and the doc doesn't do enough to explain the problem and how to avoid it.