Triggered by writing https://bugs.debian.org/971975 against lintian
(which actually was triggered by writing another bug report, #971974
:-), I noticed that in

https://www.debian.org/doc/debian-policy/ch-source.html#debian-changelog-debian-changelog

the description of the date format is inconsistent or at least ambiguous
with regards to how many digits a day of the month can have and if there
should be a zero or a space or nothing prepended to single-digit day of
months.

Especially this item made me rise an eyebrow:
"09" for single-digit day of months? And the commonly used leading space
for one-digit days of months are not mentioned anywhere.

At least the "01-31" in parentheses clashes with "one-[…]digit day of
month" in the beginning of the item. (Or does "one-digit" refer to that
the number of the day of the months can be (obviously) one digit, but
does not refer to how it's actually written? If so, this should be
clarified.)

BTW: The "date -R" mentioned in the footnote 7 uses leading zeros, at
least in Debian Sid and my timezone. (Not sure how much locales play a
role here. Actually I would expect that the shouldn't play a role in
this case at all.)

RFC 822 does not mention leading spaces:

https://tools.ietf.org/html/rfc822#section-5

But RFC 5322 seems to allow and recommend them over using only one digit
for a single digit day of month — at least if I interpret the meaning of
"[FWS]" and the according paragraph correctly:

https://tools.ietf.org/html/rfc5322#section-3.3

I'd be happy if that part of the policy could be made at least
consistent and unambiguous, e.g. by explicitly allowing all or only some
of these three formats (two characters with leading blank, two
characters with leading zero, single character). Thanks in advance!

Note: I actually have no real preference if single-digit day of month
without leading space should be allowed or not. I just want it to be
consistent and unambiguous. I though did a short check how often
single-digit day of months without leading space or zero are present,
and on my Debian Sid desktop I found about 2300 occurrences:

$ zegrep '^ -- .*  [^ ]{3}, [0-9] ' /usr/share/doc/*/changelog.Debian.gz | wc -l
2318

A leading space is clearly more often used than without, but leading
zeros are clearly in the overall majority here:

$ zegrep '^ -- .*  [^ ]{3},  [0-9] ' /usr/share/doc/*/changelog.Debian.gz | wc -l
51072
$ zegrep '^ -- .*  [^ ]{3}, 0[0-9] ' /usr/share/doc/*/changelog.Debian.gz | wc -l
137070

(Not counting those few changelog entries with non-policy-conforming
*four*-letter day of week abbreviations which the mentioned bug reports
#971974 and #971975 are about. :-)

Right. I've clarified this now locally for deb-changelog(5) as follows:

  ,---
  --- i/man/deb-changelog.pod
  +++ w/man/deb-changelog.pod
  @@ -127,7 +127,8 @@ B<Mon>, B<Tue>, B<Wed>, B<Thu>, B<Fri>, B<Sat>, B<Sun>.

   =item I<dd>

  -Is a one- or two-digit day of the month (B<01>-B<31>).
  +Is a one- or two-digit day of the month (B<01>-B<31>), where the heading
  +zero is optional, but conventionally does not get omitted.

   =item I<month>
  @@ -168,6 +169,9 @@ The “trailer” line with the maintainer and date details must be
   preceded by exactly one space (U+0020 B<SPACE>).
   The maintainer details and the date must be separated by exactly two
   spaces (U+0020 B<SPACE>).
  +Each part of the I<date> can be separated by one or more spaces
  +(U+0020 B<SPACE>), except after the comma where it can be separated
  +by zero or more spaces (U+0020 B<SPACE>).

   Any line that consists entirely (i.e., no leading whitespace) of B<#>
   or B</* */> style comments or RCS keywords.
 `---

Thanks,
Guillem

Hi Guillem,

thanks for your prompt concurrence with both, #971977 and #971975.

One nitpick:

Guillem Jover wrote:
                                                                      ^^^^^^^
[...]
                                               ^^^^^^^

You once use "heading" and once "leading". Is this on purpose? At
least for "whitespace" the term "leading whitespace" seems to be the
common one, so I'm not sure if "heading zero" is really a proper
term. (But then again, English is not my mother tongue and I might be
wrong here.)

		Regards, Axel

Hi!

Ah, thanks! I did actually doubt about that word usage, but didn't
notice the other instance after a very brief scan. :) I've amended this
now locally.

Thanks,
Guillem