The test suite has been expanded and fixed.
The date string identifies the date and time to the nearest second, so we know that the last 9 digits of the correct number of nanoseconds have to be zeros. Where are these odd, fractional numbers coming from?
We must use the function datenum to obtain the necessary data. However it is still a phony data obtained by the roundup error of dividing the number of hours by 24. For instance, 20h10 becomes 20/24 + 10/60/24 (but this decimal data has nothing to do with the passed nanoseconds of a day; it's just the best floating point representation of this fraction). The correct would be to use a dot after the seconds like '20:10:00.123' for quantities smaller than 1 second. And no dot or zeros would mean 20*3600 + 10*60 seconds.
PS: If we use datevec(now), then we may see how nanoseconds are truly displayed,, and what data is currently missing from the test suite.
Here is a solution based on the error.
For instance 73587999999895.69 is in fact 73588000000000, but since we are extracting data from converting fractional days to nanoseconds (two numbers of completely different order of magnitude, we get the error of 104.3125).
Sorry, it was not clear how to obtain these numbers from the available data.
Find state names that start with the letter N
601 Solvers
1144 Solvers
56 Solvers
93 Solvers
123 Solvers
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!