NTP timestamps are represented as a 64-bit fixed-point number, in seconds relative to 0000 UT on 1 January 1900. The integer part is in the first 32 bits and the fraction part in the last 32 bits.
But calculation of the fractional part was broken since forever, always sending 00000000 to a ntp server - fractional seconds were not being multiplied by max value of 32-bit+1 to represent the fraction in 0-[(2^32)-1] range, as expected by ntp protocol. In result, Zent_TimeSync_Ntp has always been reporting time in full-second resolution to ntp servers when syncing time.
Moreover, it triggered Implicit conversion from float-string "0.xyz" to int loses precision in Zend/TimeSync/Ntp.php:70 on PHP 8.1 and that's how I started my investigation.
NTP timestamps are represented as a 64-bit fixed-point number, in seconds relative to 0000 UT on 1 January 1900. The integer part is in the first 32 bits and the fraction part in the last 32 bits.
https://www.eecis.udel.edu/~mills/time.html https://tickelton.gitlab.io/articles/ntp-timestamps/
But calculation of the fractional part was broken since forever, always sending 00000000 to a ntp server - fractional seconds were not being multiplied by max value of 32-bit+1 to represent the fraction in 0-[(2^32)-1] range, as expected by ntp protocol. In result, Zent_TimeSync_Ntp has always been reporting time in full-second resolution to ntp servers when syncing time.
Moreover, it triggered
Implicit conversion from float-string "0.xyz" to int loses precision
inZend/TimeSync/Ntp.php:70
on PHP 8.1 and that's how I started my investigation.