How to import text to timetable with ntsf timestamp

1 visualización (últimos 30 días)
Chris
Chris el 3 de Jun. de 2019
Comentada: dpb el 7 de Jun. de 2019
Cannot figure out the syntax and/or import options to change to allow reading of text for ntsf time format into timetable.
  3 comentarios
Chris
Chris el 4 de Jun. de 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.
dpb
dpb el 4 de Jun. de 2019
NTFS ~= NTSF was the Q...

Iniciar sesión para comentar.

Respuesta aceptada

Peter Perkins
Peter Perkins el 4 de Jun. de 2019
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 comentarios
Chris
Chris el 7 de Jun. de 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
dpb el 7 de Jun. de 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>

Iniciar sesión para comentar.

Más respuestas (1)

Peter Perkins
Peter Perkins el 6 de Jun. de 2019
Editada: Peter Perkins el 6 de Jun. de 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

Categorías

Más información sobre Dates and Time en Help Center y File Exchange.

Etiquetas

Community Treasure Hunt

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

Start Hunting!

Translated by