How one can identify the date and time of a "Serial Date Number" without knowing its coding/formatting?

Question

RZM 2018-4-18

0
链接

此问题的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/395835-how-one-can-identify-the-date-and-time-of-a-serial-date-number-without-knowing-its-coding-formatti

关闭： MATLAB Answer Bot 2021-8-20

Let us say we have these serial date numbers as follows:

093789728100000e+10
093792958500000e+10
093795728500000e+10

which are related to a sequence of data sampled with 360 Hz at around this date and time: 2018-4-18 12:43:40 I tried to use the following function with all its options for 'convertfrom' but the response is not correct or at least closed to the date and time I mentioned here.

datetime(7.093789728100000e+10,'ConvertFrom','datenum')
>> ans= 
194221530 CE

Could anyone help me figure out how to decode these numbers? Thank you in advance

1 个评论
显示 -1更早的评论隐藏 -1更早的评论

Guillaume 2018-4-18

编辑：Guillaume 2018-4-18

First question is: are you sure you've read these numbers correctly? Where do they come from? A text file? A binary file? Something else?

What software or hardware was used to generate these timestamps?

此问题已关闭。

Answer 1

Walter Roberson 2018-4-18

0
链接

此回答的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/395835-how-one-can-identify-the-date-and-time-of-a-serial-date-number-without-knowing-its-coding-formatti#answer_315893

在 MATLAB Online 中打开

I have not figured out what the base offset is, but if those are intended to be 3 consecutive readings at 360 Hz, then plausibly the readings are in 10^-7 seconds and the sampling is not especially regular.

The difference between the second and third is 27700 which is suspiciously close to 1/360 * 10^7

>> 1/360
ans =
       0.00277777777777778
>> 27700/ans
ans =
     9972000

3 个评论
显示 1更早的评论隐藏 1更早的评论

Walter Roberson 2018-4-19

Speculation time:

that the system was booted around 2016-10-01 16:30:00
and that the values in the records are "ticks", with there being 4/3 * 10^7 ticks per second

These could easily be wrong.

I noticed that the last of those exact times is 0.014 seconds after the first, but that the timestamp difference is 187709 . If the 0.014 is presumed to be right then the ticks per second is between 1.26E7 and 1.44E7 depending on exactly where in the 0.013 to 0.015 range that the 0.014 falls.

If we guess this is 4/3 * 10^7 ticks per second and go 7528389331 of those ticks before 4/19/2018 7:36:03.263 then we get to about 2016-10-01 16:30:00, which is not out of the question as a device boot time for a scientific device.

Guillaume 2018-4-19

As per my comment to the question, knowing the software/hardware that generates these timestamps could go a long way towards finding out the format of the time stamps.