Module swiftnav::time[−][src]

Expand description

Time handling

GPS time counts the number of seconds since Midnight Jan 8th 1980 UTC. Leap seconds are not counted, so there is an offset between UTC and GPS time. GPS time is usually represented as a week number, counting the number of elapsed weeks since the start of GPS time, and a time of week counting the number of seconds since the beginning of the week. In GPS time the week begins at midnight on Sunday.

GpsTime is the primary representation used in swiftnav-rs. Other time bases are available, such as UtcTime, GalTime, BdsTime, and GloTime along with conversions for all of these to and from GpsTime. Not all functionality is available in these other representations, so it’s intended that all times are to converted to GpsTime before use with swiftnav-rs.

⚠️ 🦘 ⏱ ⚠️ - Leap Seconds

UTC time occasinally adds additional seconds to keep it synchronized with the slowly changing spin of the earth. This complicates time keeping, so most GNSS time bases ignore leap seconds and thus slowly grow out of sync with UTC. This is fine when dealing with GNSS data, but it’s common that people want time to be represented as a UTC time since that’s what people are more familiar with. swiftnav-rs provides ways to convert to and from UTC synchronized time bases and is able to correctly compensate for leap seconds in two ways.

The first is by using the UTC conversion parameters broadcast by GNSS systems that receivers can decode. UtcParams is how swiftnav-rs represents this information, and UtcParams::decode() is provided for decoding the raw GPS navigation subframe with this information. This is the prefered method since it is usually available when processing raw GNSS data and ensures that the right offset is applied at the right time.

The second way is to use a table of historical leap seconds that is compiled in to swftnav-rs. This list is kept up to date in the source code as new leap seconds are announced, but once the code is compiled there is no way to update this table with new leap seconds. This obviously means that sooner or later the hard coded leap second information will become out of date and the converted times will be inaccurate. This is fine if you are processing historical data, but processing live data runs the risk of an incorrect time conversion.

When converting to or from a time base that uses leap seconds (i.e. UtcTime and GloTime) two functions are always provided, one which takes a UtcParams object to handle the leap second conversion and one which doesn’t take a UtcParams object but has _hardcoded appended to the function name.