How to convert UTC timestamp to unix time in MATLAB with the respect of leap seconds

I need to synchronize two sensors from UTC to unix time. The first one is an GPS which yields an NMEA GPGGA file, where UTC timestamp has the format "HHmmss.SSS". As an example "042803.00" is "4:28:03" AM and zero milliseconds.

The second sensor yields an unix time without leap seconds.

Is there an MATLAB function which I can use? I'm especially interested in an solution which respects leap seconds? My first approach is to convert the unix time into utc:

sensor=datetime(unix_timestamp,'ConvertFrom','posixtime')

Unfortunately the argument posixtime does not support leap seconds. Then I take the utc timestamp from the NMEA file:

gps=datetime(utc_timestamp,'InputFormat','HHmmss.SSS','TimeZone','UTC')

Now since i don't have any day, year, month in my NMEA protocoll, I take it from the unix_timestamp

gps.Day=sensor.Day
gps.Month=sensor.Month
gps.Year=sensor.Year

Any Idea how to do it better? What is the risk if i take the year,month,day from the unix timestamp without leap seconds?

Now I want to transfer the gps time into unix time with:

unix_time_gps=posixtime(gps)

This does not work since posixtime does not respect leap seconds.

How do I achieve this?

Thank you

Answer 1

[Peter Perkins]

A couple things, apologies if you already know all this:

1) POSIX time does not have leap seconds. As Jan says, unix systems variously either just ignore that 86401st second, or smear it over the entire day. That's why 'ConvertFrom','posixtime' doesn't support leap seconds -- POSIX time doesn't. And strictly speaking, POSIX time is not a "timestamp" in the sense of hh:mm:ss, it's a count of seconds. "Doesn't support leap seconds "means that the count does not increment during a leap second.

2) UTC, i.e. the "real-world" UTC, does observe leap seconds. The 'UTC' timezone that datetime in MATLAB supports is more like POSIX time in that it ignores the existence of leap seconds, because most people would be unhappy to find their calculations puzzlingly off by, say, 2 seconds when going from noon to noon. 'UTCLeapSeconds' is for those who need the exact thing.

3) GPS time also does not observe leap seconds, but in a different way than POSIX time doesn't. It is also a count of elapsed time, but the count DOES increment during a leap second, and therefore GPS time drifts from UTC by 1 second each time a leap second occurs in UTC. So, you should be really careful that the thing you are calling "GPS time" and "UTC timestamp" is in fact what you think it is. I don't even know what a NMEA GPGGA file is, so you're the expert here.

It looks like your unix_timestamp is a number, and your utc_timestamp is text in the format "HHmmss.SSS". In some sense it does not matter if you use

datetime(utc_timestamp,'InputFormat','HHmmss.SSS','TimeZone','UTC')

or

datetime(utc_timestamp,'InputFormat','HHmmss.SSS','TimeZone','UTCLeapSeconds')

because that timestamp is absolute, not relative (once you get the right date for it, and assuming you can synchronize the two data streams), and datetime is happy to convert either ''UTC' or 'UTCLeapSeconds' times into the correct POSIX time. If your data are never at 23:59:60.xxx on 30-Jun or 31-Dec, everything is fine, both of those lines work, and datetime automatically compensates for leap seconds when converting from 'UTCLeapSeconds' to POSIX time. If your data do happen to land during an actual leap second, the first line above will error, the second will work, but again datetime compensates -- calling posixtime will give you the value that the POSIX time for that leap second would be -- the 0th second of the next day.

So what is it that "does not work since posixtime does not respect leap seconds"?

Answer 2

[Jan]

It depends on how the unix time stamps are created. Actually unix time and UTC is synchronized. Then computers writing time stamps in unix either repeat the the correspodnign second, or the surrounding seconds are shortend or expanded accordingly to preserve the linear time stamps. It depends on the implementation.

In consequence you can be sure that the unix time stamps use 86'400 seconds per day and you get an easy relation between unix time and UTC.

Finally I do not see any risk of taking the date from the unix time stamp, because this should be perfect, except for the duration during the leap second.

Can you post a specific example to demonstrate that there is a problem with the leap seconds? Maybe I've overseen a detail.

[Sean de Wolski]

Also be sure to look at the UTCLeapSeconds TimeZone

https://www.mathworks.com/help/matlab/ref/datetime.html#buhzxmk-1-TimeZone

[Muhammad Taher]

Hi All,

24:02:2020 at 00:00:00 equavalent GPS time =1266537370.000 and End GPS time Te=1266762998.200(25:02:2020 at 24:00:00 hours).

Is there any function, I can use to convert others GPS time for example [1266762758.200,1266762038.200,...].

I want a conversion systems all GPS time in local time means = 24:02:2020 at 10:00:00,11:00:00,.... like this

Thanks in advance.

[Peter Perkins]

This question belongs in another thread.

But obviously your numbers can not be correct, because 6-Jan-1980 + 1266762998.200 seconds can't possibly end up at an even number of hours, and 24-Feb-2020 00:00:00 to 26-Feb-2020 00:00:00 (equivalent to 25-Feb-2020 24:00:00) can't possibly be 225628.2 seconds.

GPS time is tricky, and one needs to be precise. Let's assume that by 1266762998.200, you mean "126... elapsed seconds after the GPS time origin." On the true civil UTC timeline that includes leap seconds, that ends up at

>> datetime(1980,1,6,'TimeZone','UTCLeapSeconds') + seconds(1266762998.200)
ans = 
  datetime
   2020-02-26T14:36:20.200Z

On the GPS timeline, where leap seconds are not observed, it ends up (in the standard civil notation on the GPS timeline, rather than the more usual weeks/seconds GPS notation) as 26-Feb-2020 14:36:38.200 -- 18 seconds difference, because of the 18 leap seconds between 1980 and now.

So it's not clear what you are asking about. But in any case, you should start a new thread.