Different time stamps using datestr and datetime
3 views (last 30 days)
Show older comments
Hi,
I have used accumarray to minutely median average a vector, s_temp using a datenum vector time_temp:
[Yr,Mt,Dy,Hr,Mn,~] = datevec(time_temp(1));
t_zero = datenum(Yr,Mt,Dy,Hr,Mn,0);
[Yr,Mt,Dy,Hr,Mn, ~] = datevec(time_temp(end));
t_end = datenum(Yr,Mt,Dy,Hr,Mn+1,0);
tbin = (t_zero:1/24/60:t_end).';
[~, idx] = histc(time_temp, tbin);
sz = [max(idx) 1];
s_median = accumarray(idx, s_temp, sz, @median, NaN);
Then I have tested the timetable function to do the same (out of curiosity):
ts = timetable(datetime(time_temp,'ConvertFrom','datenum'),s_temp);
TS = retime(ts,'minutely',@median);
The estimated median values unfortunately disagree occassionally, and I have realized that the problem is related to the datetime function. It seems like it rounds the datenum value to the seventh decimal place. See the example below:
RunDate=7.372784756944444e+05;
datestr(RunDate)
datetime(RunDate,'ConvertFrom','datenum')
Is there a way to come around this problem or anybody else who has encountered it?
Grateful for any help!
0 Comments
Accepted Answer
Walter Roberson
on 5 Feb 2020
Edited: Walter Roberson
on 6 Feb 2020
The best numeric approximation for that minute is the next representable number after RunDate, roughly 1e-10 larger. You would not be able to see the difference in low bit with any of the default numeric formats, and would need to use num2strexact from the file exchange for Windows, or use fprintf with a larger number of decimal places for Mac or Linux. In short, your literal constant for RunDate would need one more digit to force the bottom bit to be correct when converted to binary.
RunDate is
737278.475694444379769265651702880859375
The best datenum for the minute is
737278.4756944444961845874786376953125
More Answers (0)
See Also
Categories
Find more on Time Series Objects in Help Center and File Exchange
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!