Subject: bug#26260: closed (Re: bug#26260: ~f SRFI-19 format specifier mishandles one-digit seconds value)

From: [email-masked] (GNU bug Tracking System)
Date: Wed, 19 Apr 2017 13:48:02 +0000

Your bug report

#26260: ~f SRFI-19 format specifier mishandles one-digit seconds value

which was filed against the guile package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
26260: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=26260
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#26260: ~f SRFI-19 format specifier mishandles one-digit seconds value
From: Andy Wingo <[email-masked]>
To: [email-masked]
Date: Wed, 19 Apr 2017 15:46:54 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

thanks

Subject: ~f SRFI-19 format specifier mishandles one-digit seconds value
From: Zefram <[email-masked]>
To: [email-masked]
Date: Sun, 26 Mar 2017 03:09:29 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

The ~f format specifier for SRFI-19's date->string is documented as:

#    ~f     seconds and fractional seconds, with locale
#           decimal point, eg. `5.2'

Let's test that example:

scheme@(guile-user)> (use-modules (srfi srfi-19))
scheme@(guile-user)> (date->string (make-date 200000000 5 34 12 26 3 2017 0) "~f")
$1 = "05.2"

That's not the documented format: the doc and the SRFI itself show "5.2"
with no leading padding, but actual behaviour is to zero pad.  There is
much that is ambiguous in the SRFI's specification of ~f, but with that
example it does at least seem clear that there should be no padding there.

-zefram