On Tue, 18 Feb 2025 00:22:16 +1000 (AEST) David Leonard <[email protected]> wrote:
Hello David, This is the first time I've thought about NTP eras, so I'm not sure my reasoning is correct, but here are my considerations: in lpf_to_d, d was calculated by adding 1<<32 to dates < 1970, so d is always the number of seconds since 1900-01-01T00:00:00.0 - no era here. Now we have to go back, using d_to_lpf Say time_t is 64 bits. then (time_t)d is never limited to maxInt64 for the next 500E9 years. If 1970 < d < 02.07.2036 then (time_t)d is a full 32 bit quantity: actual era. If d > 02.07.2036 then (time_t)d is a 33 bit quantity, where 33 bit = 1 and 32 bits = 0. Casting to an uint32_t takes only the lower 32 bits and represents a date in the next era. Now, lets say time_t is 32 bit. if d > 0x7fff.ffff, then float conversion of (time_t)(d) is screwing us. We get 0x7fff.ffff, that is 20.01.1968. if we do (uint32_t)d, (like I did), the float conversion limit the value to 0xffff.ffff, and we can't switch era. Hence we should do: uint32_t intl = (uint32_t)(int64_t)d; uint32_t frac = (uint32_t)((d - (int64_t)d) * 0xffffffff); and this is also correct in case of 64 bit time_t. A good point is that we never calls for time_t: Writing this E-Mail I came to the conclusion that time_t here only creates confusion between unix date and ntp data. About the starting point, the only comment I can make, is that we must be sure that a system starting with unix time_t = 0 - no battery in the real time clock - starts in the right era. I hope my reasoning can help you, Best regards, Ruggero I hope may _______________________________________________ busybox mailing list [email protected] https://lists.busybox.net/mailman/listinfo/busybox
