Chris

After more deliberation, I think ANISE should support OEM files as an extra field in the Almanac. The primary reason is that ANISE has an extensive and well used Python...

A real poweruser! I'll let you know when it's ready to test. I can't imagine this being too much work to be honest: it took me a very short amount...

Thanks for helping on this branch! I was about to pick up the work today, so the multiple timezones really helps! > I see that you are removing `.centuries` from...

Hmm, I didn't quite expect this problematic behavior: the `f64` is not precise enough to accurately convert to an i128 without loss of precision. For example, when initializing `Duration::from_seconds(10.1)`, the...

I think that this problem can be solved using a GCD algorithm like the one I introduced here (for hifitime v2): https://github.com/dnsl48/fraction/pull/37/files#diff-34e20107d75000e9bae6843d1fa9f42adf14f11c2334d8e32a98321010c2a194R2306 . This should only be called when initializing...

That approach worked out of the box! Now I have another issue in `DurationParts` where the `to_unit` shows some rounding errors: ``` [src/duration/mod.rs:595:13] dt = Duration { zeptoseconds: 86400000000099000000000000, }...

The approach I implemented last night works, but it's _significantly_ slower than the current version of `Duration`. This slowness is especially obvious with the "convert f64 to duration" benchmark, which...

Yes, that makes sense actually, and I had not considered this. In the long run, it most likely prevents a lot of bugs, but is it worth the 2x slow...

> to be more accurate, it is incorrect to say most operations are floating point, right ? the current infrastructure uses fixed point at its very basis. Unless you are...

Switching to increments of 1000 when converting from f64 does not significantly improve speed: https://github.com/nyx-space/hifitime/actions/runs/10569484722?pr=326 .