hifitime
hifitime copied to clipboard
Epoch::from_time_of_week returns wrong time in GPST
When using Epoch::from_time_of_week
to initialise Epoch
from a GPS week number and time of week, the resulting epoch has a 19 second offset. Below is a sample program that shows the bug:
use hifitime::{Epoch, TimeScale};
fn main() {
let t = Epoch::from_time_of_week(1983, 0, TimeScale::GPST);
println!("{:#?}", t);
// Should print "2018-01-07T00:00:00 GPST"
let t = Epoch::from_time_of_week(1982, 604800000000000 - 19000000000, TimeScale::GPST);
println!("{:#?}", t);
}
Currently this prints:
2018-01-07T00:00:19 GPST
2018-01-07T00:00:00 GPST
Also, as a feature request it would be handy to have a version of from_time_of_week
and from_time_of_week
that works on f64
seconds instead of nanoseconds
Thanks for the bug report. This looks similar to an issue we had in the PR that added GPST. I know we fixed it, but I forget how right now.
How urgently does this bug need fixing for you?
On Sat, Mar 18, 2023, 03:44 Leith Bade @.***> wrote:
Also, as a feature request it would be handy to have a version of from_time_of_week and from_time_of_week that works on f64 seconds instead of nanoseconds
— Reply to this email directly, view it on GitHub https://github.com/nyx-space/hifitime/issues/209#issuecomment-1474790333, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABEZV2HHXI5MQOOCWVG6UODW4V7YPANCNFSM6AAAAAAV7J3MJA . You are receiving this because you are subscribed to this thread.Message ID: @.***>
It's not urgent, I was able to work around it by just subtracting the 19 second offset to value I give to from_time_of_week
Possibly related to this bug, if you provide the same time in two different GNSS timescales you get the wrong values in UTC. For example if I use GPST and BDT then I get the same incorrect time in UTC for both.
A test:
se hifitime::{Epoch, TimeScale};
fn main() {
let t = Epoch::from_time_of_week(1983, 0, TimeScale::GPST);
println!("{:#?}", t);
// Should print "2018-01-07T00:00:00 GPST"
let t = Epoch::from_time_of_week(1982, 604800000000000 - 19000000000, TimeScale::GPST);
println!("{:#?}", t);
let t_gps = Epoch::from_gregorian(2023, 03, 12, 00, 00, 00, 0, TimeScale::GPST);
println!("{}", t_gps);
// Should print "2018-01-06T23:59:42 UTC"
let t_bdt = Epoch::from_gregorian(2023, 03, 12, 00, 00, 00, 0, TimeScale::BDT);
println!("{}", t_bdt);
// Should print "2018-01-06T23:59:56 UTC"
let delta_t = t_bdt - t_gps;
println!("{}", delta_t.in_seconds());
// Should print "14"
}
This prints currently:
2023-03-11T23:59:23 UTC
2023-03-11T23:59:23 UTC
0
The UTC time printed seems to be always 37 seconds off from the input time. 37 seconds I think is also the difference between UTC and TAI, so perhaps both times are being interpreted as TAI?
Thanks for the report, that does look like there is a wrong interpretation of the leap seconds.
@gwbres Any thoughts on this issue?
Thank you @ljbade for the bug report !
If i remember correctly, 19 is the amount of leap seconds when GPST was initiated (1980 Jan 5th to 6th midnight). My first guess would be a problem of bad TAI referencing? we're supposed to always refer to TAI in our calculations
Yes GPS is 19 seconds offset from TAI, and BDT is 33 seconds.
Hey @ljbade , if that's OK, I'll work on this for version 4.0.0. As explained in #237 , I think that things get confused in between the GNSS time scales.
Hi @ljbade ,
I think that I've fixed the bug in #303 . Here is the test I'm about to add to the regression tests and the output I got. The first case matches exactly what you said it should be, and I'd like your confirmation that the second output is also correct.
Thanks
#[test]
fn regression_test_gh_209() {
let t = Epoch::from_time_of_week(1983, 0, TimeScale::GPST);
println!("{t}");
// Should print
assert_eq!(format!("{t}"), format!("2018-01-07T00:00:00 GPST"));
let t = Epoch::from_time_of_week(1982, 604800000000000 - 19000000000, TimeScale::GPST);
println!("{t}");
}
Output:
---- regression_test_gh_209 stdout ----
2018-01-07T00:00:00 GPST
2018-01-06T23:59:41 GPST
successes:
regression_test_gh_209
Done in #305 .