Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.