Does anyone know is there any function that will give me GPS time (now)? I need it to calculate time since reference epoch (tk = t – to) in seconds.
MATLAB: Get GPS time to calulate time since referencje epoch
epochgpssatellitetime
Related Solutions
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"?
James, in the second instance, you're subtracting 2012-06-30T00:00:24.000Z from 2012-07-02T00:00:25.000Z. There really is 86401+86400+1 seconds difference, i.e. 2*86400 + 2, because of the one leap second and the 1s diffference in the times of day. I think the confusion stems from the diff between what you did and this:
>> t1 = datetime(2012,6,30,0,0,0,'TimeZone','UTCLeapSeconds')t1 = 2012-06-30T00:00:00.000Z>> t2 = datetime(2012,7,2,0,0,0,'TimeZone','UTCLeapSeconds')t2 = 2012-07-02T00:00:00.000Z>> t2 - t1ans = 48:00:01
That's 48h and 1s. I will make a note to look into the conversion from "unzoned" to 'UTCLeapSeconds', and why you get those extra seconds.
In the third case, you're running 14b, which was released before the 2015 leap second was even announced. There was a patch posted in early January, and the recently-released 15a has the patch already in it. You're right, there needs to be more communication about how to update, although given the current state of affairs, it's not even clear that there will ever be any more leap seconds.
Hope this helps.
Best Answer