Convert UNIX NanoSeconds to DTG in Milliseconds

Hello,

I have to do 2 things: convert UNIX nanoseconds to DTG Nanoseconds, and then convert DTG Nanoseconds to DTG Milliseconds. The second conversion would be a "SUM" of all the entries into one millisecond. So for every nanosecond entry within millisecond "1," I would like to sum the different parts of the table and add them together to create a millisecond register instead of a nanosecond register. Does this make sense? Any questions are welcomed in order to reach this goal!

Thanks,

Tim

[Walter Roberson]

What do you want to do about the fact that Unix time and DTG handle leap seconds differently?

[Walter Roberson]

What is the representation of the nanoseconds ?

Double precision values cannot store enough precision to reach nanoseconds with Unix epoch time stamps.

You need int64 or uint64 to be able to store the nanoseconds as integers -- but then you have challenges in converting them.

[Timothy]

I found this on another answer string:

What you have is 1ns ticks since 1970. That's sort of Posix time, but at a different resolution. If that's really what you have, you are gonna need to store the raw numbers as a uint64 array, double will not give you enough precision. So

ThemeCopy

>> t = uint64(1545390864126080000)

t =

uint64

1545390864126080000

>> d = datetime(t,'ConvertFrom','epochtime','TicksPerSecond',1e9,'Format','dd-MMM-yyyy HH:mm:ss.SSSSSSSSS')

d =

datetime

21-Dec-2018 11:14:24.126080000

If you don't care about anything smaller than ms, then you can use double.

ThemeCopy

>> t = 1545390864126

t =

1545390864126

>> d = datetime(t,'ConvertFrom','epochtime','TicksPerSecond',1e3,'Format','dd-MMM-yyyy HH:mm:ss.SSS')

d =

datetime

21-Dec-2018 11:14:24.126

[Timothy]

For the previous answer, the poster said his nanoseconds were represented in something like 1.6e18, whereas the data provider told me to convert it to 1.6e9 to get proper UNIX nanoseconds. I already converted them to a 1.6e9 format. I don't know the solution to the leap second problem, but do you think the above solution would work or not?

[dpb]

You've not answered @Walter Roberson's fundamental question -- how are the data available to start with -- there's not enough precision (significant digits) in an IEEE double to hold the nanoseconds to begin with -- writing 1.6E18 will write that many decimal places, but they don't mean anything after about 15 -- if there's a text file containing long integers to read, that's one way you could start, but then if you read them in as doubles, they're going to be truncated at the precision of a double and you've lost the nanoseconds already before ever started.

[Timothy]

Okay, so "correction." The numbers are truncated after 16 digits, the first digit being a "1." The nice thing is, I don't need nanoseconds, just milliseconds, which is 1e3 instead of 1e9. I converted the column in the table to be stored as uint64, then I used the above formula to convert them into a Date-Time Group, and this is an example of what I get:

26-Jun-2023 14:25:15.108205312

9 digits after the "seconds" digits, indicating nanosecond-level precision. If you are asking how I imported it as such, I do not know, I simply got it from the data provider and imported it. I am going to convert it to just millisecond precision, because nanoseconds is actually too precise for my uses.

[Timothy]

Now that I have it in Date-Time with nanoseconds, any ideas how to simply round it off to milliseconds?

[Walter Roberson]

If you had the time in int64 or uint64 nanoseconds, then to round to milliseconds, just divide them by 1000: operations on integer data classes automatically round

If you have double precision numbers, then see round which has the ability to indicate how many digits you want to round to.

Answer 1

[dpb]

Ah! That simplifies the problem immensely; you've already passed the hard part.

To do the initial request to sum over millisec time intervals, turn the data table into a timetable and use retime with the 'regular' sample rate and @sum method...

tt=timetable(yourdatetimevar,restofdata);
ttMS=retime(tt,'regular','sum','SampleRate',1000);  % aggregate a msec sample rate

The above will start at the actual time in msec and aggreate within those groups; it will not resample to approximate at even msec times. If want that, use retime() and interpolate first, then aggregate. There may be a way to do both in one step, I'm not sure.