from_time_of_week is not the reciprocate of to_time_of_week when the reference epoch is J1900

[ChristopherRabotin]

The following fails, and I just do not understand why:

let epoch_utc = epoch.in_time_scale(TimeScale::UTC);
println!("{epoch:?}\t{epoch_utc:?}");
let (utc_wk, utc_tow) = epoch_utc.to_time_of_week();
assert_eq!(Epoch::from_time_of_week_utc(utc_wk, utc_tow), epoch_utc);

There is an offset of one day.

My hunch is that something is wrong with to_time_of_week but I don't understand why or where.

This happens for UTC, TT, and TAI. For ET and TDB, there is a small offset, most likely due to these time scales using an iteration for initialization (but that is not an "exactly one day" time error).

Note: this is currently hot fixed in the code of from_time_of_week.

[gwbres]

@ChristopherRabotin
I identified the problem but I have not found a way to solve it right now

The problem is specific to the new methods

• to_time_of_week
• from_time_of_week

the week counter specificly.

In these methods, we're trying to build an epoch, in a time scale, from a week counter.
And we do not consider a possible day offset, due to the time scale weekday starting point.

Take TAI/UTC that started on a Monday.
I'm pretty sure TAI <=> UTC operations work perfectly fine.

Apparently, all GNSS timescales started on a Sunday.
Take a GPST <=> UTC operations, we get the +/-1 day offset because we only consider an modulo operation, which only works in TAI.

The sign will different depending on the UTC => GPST or GPST => UTC operation order.
I'm pretty sure if you take GSPT <=> GST operations, you will get the correct results

We probably need something like this

        // week counter
        let mut week = div_euclid_f64(
            self.to_duration().to_unit(Unit::Day),
            Weekday::DAYS_PER_WEEK,
        ); // this is OK in TAI
        
        week -= time_scale.ref_weekday(); // Counter offset
        
        // the following is only to determine the offset within that week
        // and it works fine
        let mut start_of_week = self.previous_weekday_at_midnight(Weekday::Sunday);
        let ref_epoch = self.time_scale.ref_epoch();
        // restrict start of week/sunday to the start of the time scale
        if start_of_week < ref_epoch {
            start_of_week = ref_epoch;
        }
        let dw = *self - start_of_week; // difference in weekdays [0..6]
        (wk as u32, dw.nanoseconds)

Just give me a couple of more hours, I may have a solution

[ChristopherRabotin]

Ah, interesting. So then we can solve this by changing the reference weekday: for the GNSS, keep the previous Sunday as the start of the week (because that's formally defined). But for the other ones, we would use the week day of the ref epoch. What do you think?

…

On Tue, Dec 6, 2022, 02:51 gwbres ***@***.***> wrote: I identified the problem but I have not found a way to solve it The problem is specific to the new methods - to_time_of_week - from_time_of_week the week counter specificly. In these methods, we're trying to build an epoch, in a time scale, from a week counter. And we do not consider a possible day offset, due to the time scale weekday starting point. Take TAI/UTC that started on a Monday. I'm pretty sure TAI <=> UTC operations work perfectly fine. Apparently, all GNSS timescales started on a Sunday. Take a GPST <=> UTC operations, we get the +/-1 day offset. The sign will different depending on the UTC => GPST or GPST => UTC operation order. I'm pretty sure if you take GSPT <=> GST operations, you will get the correct results — Reply to this email directly, view it on GitHub <#187 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABEZV2CEG5G5BCDYDXPWUR3WL4EB7ANCNFSM6AAAAAASVDYLFU> . You are receiving this because you authored the thread.Message ID: ***@***.***>