SRFI-19 padding error

[Alex Kicelew]

SRFI-19 defines ~k converter of date->string as blank-padded variant of ~H, but sagittarius treats it as ~H and pads with zero.

(import (scheme base)
        (scheme write)
        (srfi 19))

(let* ((d (make-date 0 1 2 3 4 5 2006 0)))
  (display (date->string d "~a ~b ~e ~k:~M:~S ~Y"))
  (newline))

expected: Thu May 4 3:02:01 2006

got: Thu May 4 03:02:01 2006

[Takashi Kato]

Thank you for the report!
I’ve checked the reference implementation of SRFI-19 which I’ve ported 10+ years ago, and it also provides the '0'.
https://github.com/scheme-requests-for-implementation/srfi-19/blob/master/srfi-19.scm#L1055

I’m afraid that fixing this would break portability. I’ll ask this on the SRFI mailing list.

[Takashi Kato]

Question sent: https://srfi-email.schemers.org/srfi-19/msg/16454218/

[Alex Kicelew]

Thank you. I would add the following information. If I understand right, SRFi-19’s date->string and string->date are modeled after very old UNIX' strftime (format time) and strptime (parse time) functions, which both accept the same format identifiers as SRFI-19, only with % instead of ~. And strptime always formats %k and %l as blank-padded digits if they’re less than 10, and %H and %I as zero-padded.

[Takashi Kato]

Created a pull request to the SRFI: https://github.com/scheme-requests-for-implementation/srfi-19/pull/5
I’ll apply the same fix after it’s merged.

[Takashi Kato]

Following ~k directive change of SRFI-19 (fixes #273)

→ <<cset 863add34a773>>