MATLAB Answers

Different values of datnumber for same date-time?

6 views (last 30 days)
Abhinav
Abhinav on 5 Aug 2018
Edited: dpb on 8 Aug 2018
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.

  0 Comments

Sign in to comment.

Accepted Answer

dpb
dpb on 6 Aug 2018
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.

  4 Comments

Show 1 older comment
dpb
dpb on 6 Aug 2018
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.
dpb
dpb on 6 Aug 2018
No problem; it's a very common issue and the doc doesn't do enough to explain the problem and how to avoid it.

Sign in to comment.

More Answers (0)

Sign in to answer this question.

Tags

Products


Release

R2014a