Returns wrong Day of Year

gwbres commented 7 months ago

Hello,

let epoch = Epoch::from_str("2021-12-21T00:00:00 GPST")
   .unwrap();

// weird result
println!("{:?}", epoch.years_days_of_year());
(1941, 29574.0)

// wrong result
println!("{:?}", epoch.day_of_year());
29574.0

gwbres commented 7 months ago

This happens with GNSS timecales, which are not tested in the DOY testbench.

ChristopherRabotin commented 7 months ago

Hi Guillaume,

What is the expected result here? If I remember correctly, there's an ambiguity in calculating the year because of the reference year, but I forget where that ambiguity lies.

gwbres commented 7 months ago

What is the expected result here?

(2021, 355)

doy should be a value < 365 as you would expect. Currently we get (1941, 29k), where 29k = (2021 - 1941 )* 365 + 355

ChristopherRabotin commented 7 months ago

I have a fix in progress, but there is an issue with GPST because the GPST ref epoch starts on 06 January and not 01 January. So should, for example "01 Jan 2022 GPST" return a day in year of zero (because zero full days have gone by) or should it return 360?

gwbres commented 7 months ago

I think it should return 0 because in DOY use cases, we usually imply the gregorian calendar. What do you think ?

I don't think we can use python as a reference on this one 😆

ChristopherRabotin commented 7 months ago

Yup, according to NOAA, the counter starts at 1 and starts on 01 January.

gwbres commented 7 months ago

curious to read where the problem lies, once you submit it.

If we're certain about things, I'm interested in having a new release of your library, because

the new "%y formatter will facilate my parsers
I am about to support RINEX standard naming conventions, and they use the DOY everywhere. Most navigation data (interesting RINEX files) work in GNSS timescales (GPST, 99% of the time). In this case, I workaround this very issue by converting to UTC, which slightly offsets the file name we generate 😆

ChristopherRabotin commented 7 months ago

Let's make it happen!

gwbres commented 7 months ago

Thank you for all your support Chris. Now I only have one more thing to do: correct my support of Clock RINEX and I'm off to PPP 😅 PPP will illustrate nyx a lot more than SPP

ChristopherRabotin commented 7 months ago

Sweet, looking forward to it!

On Sat, Dec 30, 2023, 15:14 gwbres @.***> wrote:

Thank you for all your support Chris. Now I only have one more thing to do: correct my support of Clock RINEX and I'm off to PPP 😅 PPP will illustrate a lot more nyx

— Reply to this email directly, view it on GitHub https://github.com/nyx-space/hifitime/issues/272#issuecomment-1872616289, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABEZV2BTGCTISGONT34IQ6TYMCG2TAVCNFSM6AAAAABBHPQPDKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZSGYYTMMRYHE . You are receiving this because you commented.Message ID: @.***>

gwbres commented 7 months ago

If you're fine with waiting until tomorrow, I will then add one or two similar tests to #273 for BDT/GST

ChristopherRabotin commented 7 months ago

Good idea.

On Sat, Dec 30, 2023, 15:46 gwbres @.***> wrote:

If you're fine with waiting until tomorrow, I will then add one or two similar tests to #273 https://github.com/nyx-space/hifitime/pull/273 for BDT/GST

— Reply to this email directly, view it on GitHub https://github.com/nyx-space/hifitime/issues/272#issuecomment-1872620352, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABEZV2FGN37A3SPAZEG7MEDYMCKTDAVCNFSM6AAAAABBHPQPDKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZSGYZDAMZVGI . You are receiving this because you commented.Message ID: @.***>

nyx-space / hifitime

Returns wrong Day of Year #272