MATLAB Answers

Chris
0

How to import text to timetable with ntsf timestamp

Asked by Chris
on 3 Jun 2019
Latest activity Commented on by 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.

  3 Comments

https://docs.microsoft.com/en-us/windows/desktop/sysinfo/file-times on the assumption NTSF --> NTFS If not, never heard of it.
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.
NTFS ~= NTSF was the Q...

Sign in to comment.

2 Answers

Answer by Peter Perkins
on 4 Jun 2019
 Accepted Answer

In recent versions (since R2018a? or thereabouts):
>> help datetime
[snip]
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:
[snip]
'ntfs' The number of 100ns "clock ticks" since 1-Jan-1601 00:00:00 UTC
[snip]
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.

  6 Comments

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.
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.
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.


Answer by Peter Perkins
on 6 Jun 2019
Edited by 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 =
1.466e-06

  0 Comments

Sign in to comment.