GNU bug report logs - #26261
~N mishandles small nanoseconds value

Previous Next

Full log

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Zefram <zefram <at> fysh.org>
To: bug-guile <at> gnu.org
Subject: ~N mishandles small nanoseconds value
Date: Sun, 26 Mar 2017 03:19:24 +0100

The ~N format specifier in SRFI-19's date->string is documented to show
the nanoseconds value, with zero padding.  The documentation explicates
further by showing as an example a string of nine zeroes.  In fact the
implementation only pads to seven digits, and so produces incorrect
output for and nanoseconds value in the range [0, 100000000):

scheme@(guile-user)> (use-modules (srfi srfi-19))
scheme@(guile-user)> (date->string (make-date 0 5 34 12 26 3 2017 0) "~N")
$1 = "0000000"
scheme@(guile-user)> (date->string (make-date 2 5 34 12 26 3 2017 0) "~N")
$2 = "0000002"
scheme@(guile-user)> (date->string (make-date 200 5 34 12 26 3 2017 0) "~N")
$3 = "0000200"
scheme@(guile-user)> (date->string (make-date 200000 5 34 12 26 3 2017 0) "~N")
$4 = "0200000"
scheme@(guile-user)> (date->string (make-date 99999999 5 34 12 26 3 2017 0) "~N")
$5 = "99999999"
scheme@(guile-user)> (date->string (make-date 200000000 5 34 12 26 3 2017 0) "~N")
$6 = "200000000"

The padding clearly has to be to the full nine digits.

-zefram

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.