Closed guillermoacdc closed 3 years ago
I've been having the same problem. I'd recommend you replace the time_converter method for absolute time with winrt::clock::to_file_time(timestamp.TargetTime()).value;
whereby timestamp results from
winrt::Windows::Perception::PerceptionTimestampHelper::FromSystemRelativeTargetTime(
hundreds_of_nanoseconds(temp_timestamp.HostTicks));
I modified the TimeZone with respect to UTC (UTC-6) and updated the expected date; there was a mistake. The result is more confindent now
Expected date: 2021-07-01 15:11 PM
TimeStamp:132696439088603000
granularDate:2021-07-01 15:11:48.860
dateType:ntfs; 100nanoseconds for each tick, from 01/01/1601 TimeZone: 'America/Chicago'
A video explaning basic concepts here : https://www.youtube.com/watch?v=SSmSNqNkGLU&t=283s
Overarching goal: Decodificate the timestamp recorded by StreamRecorder Application (file Depth Long Throw_rig2world.txt) in the format 'yyyy-MM-dd HH:mm:ss.SSS'
When trying to decodificate, i have used datetypes: {'ntp', '.net', 'ntfs'} but the result is not the one i was expecting
sample value: 132702448095356149 expected date: 2021-07-09 17:29.... from registration of time in place Results [ datetype value]: ntfs 2021-07-07 20:20:55.506 net 0421-07-07 20:20:55.506 ntp 1900-12-24 14:30:05.590