MATLAB Answers

How to import text to timetable with ntsf timestamp

5 views (last 30 days)
Chris on 3 Jun 2019
Commented: dpb on 7 Jun 2019
Cannot figure out the syntax and/or import options to change to allow reading of text for ntsf time format into timetable.


Chris on 4 Jun 2019
It is Windows file time. I had not heard of it either but 'ntfs' is what it is called in MatLabs datetime format documentation. I can convert a numeric array to it, but have not found the syntax to import it from a file into a timetable without importing the arrays individually and then building the timetable.

Sign in to comment.

Accepted Answer

Peter Perkins
Peter Perkins on 4 Jun 2019
In recent versions (since R2018a? or thereabouts):
>> help datetime
D = datetime(X,'ConvertFrom',TYPE) converts the numeric values in X to
a datetime array D. D is the same size as X. TYPE specifies the type of
values contained in X, and is one of the following:
'ntfs' The number of 100ns "clock ticks" since 1-Jan-1601 00:00:00 UTC
D = datetime(X,'ConvertFrom','epochtime','Epoch',EPOCH) converts the
numeric values in X to a datetime array D. X contains the number of
seconds before or since the epoch. EPOCH is a scalar datetime or a
date/time character vector or string scalar, representing the epoch
time. The default epoch is 1-Jan-1970 00:00:00 UTC.
D = datetime(X,'ConvertFrom','epochtime','Epoch',EPOCH,'TicksPerSecond',N)
converts the values in X from the numeric time representation specified
by EPOCH and N, to a datetime array D. X is a numeric array
representing time as the number of "clock ticks" before or since the
epoch time. EPOCH is a scalar datetime or a date/time character vector
or scalar string that specifies the epoch time. N is a scalar integer
that specifies how many clock ticks there are per second.


Show 3 older comments
dpb on 7 Jun 2019
Nicely done...but why don't you set the appropriate 'VariableType' for the NTFS datestamp to uint64 in the import options object to do the type cast on read? As Peter illustrated you're losing precision in the input process as there aren't sufficient bits in a double to store a 64-bit int.
Chris on 7 Jun 2019
For maximum precision I concur with the need to import as uint64. I had not noticed because in my application the time variable is timestamps on data sampled up to 20 kHz. 50 us vs 100 ns count would require losing more than 9 bits of precision to notice. For my current application it makes no significant difference other than the extra step of specifying the import option. But I agree it is in general good practice.
dpb on 7 Jun 2019
But, since you're writing generic code and creating the import object anyways, why not go to the earliest source possible? Then the code is generic and usable in the future even if the timestamp granularity changes. And then there's the secondary advantage the anonymous function is simpler without the cast operation.
I don't know as I've not tried to run a timing test, but my first guess is that performance would be better with the translation on input as opposed to in the function as well, but that's conjecture, granted.
You seem to have gone to considerable pains to get this far, why not complete the job? <VBG>

Sign in to comment.

More Answers (1)

Peter Perkins
Peter Perkins on 6 Jun 2019
Edited: Peter Perkins on 6 Jun 2019
"it only accepts a number formated as uint64"
NTFS timestamps are defined as 64bit numbers. Anything smaller than that and you get round-off. For contemporary timestamps, if you put an NTFS timestamp into a double, you'll only get about 1microsec resolution.
>> (seconds(datetime('now') - datetime(1601,1,1))) / flintmax
ans =


Sign in to comment.

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by