The ~f format specifier in SRFI-19's date->string function is supposed to produce a decimal string representation of the seconds and nanoseconds portions of a date together:
scheme@(guile-user)> (use-modules (srfi srfi-19)) scheme@(guile-user)> (date->string (make-date 550000000 56 34 12 26 3 2017 0) "~f") $1 = "56.55" but it screws up for nanoseconds values in the range (0, 1000000), i.e., for any time that lies strictly within the first millisecond of a second: scheme@(guile-user)> (date->string (make-date 550000 56 34 12 26 3 2017 0) "~f") $2 = "56.5e-4" Looks like the fractional seconds value is being formatted through a mechanism that is not suitable for this purpose, which uses exponent notation for sufficiently small values and thereby surprises the date->string code. Note that just assembling the seconds+fraction value and putting the whole thing through the same formatter, as opposed to putting the fractional part through on its own, would fix the above test cases, and any others with non-zero integer seconds, but would leave the bug unfixed for the case where the integer seconds value is zero. Fixing this requires not using any formatting mechanism that would ever resort to exponent notation for values in the relevant range. -zefram
