[PATCH] man*/: ffix

[PATCH] man*/: ffix

[Guillem Jover]

Escape dashes on dates, UUIDs, URLs, file and package names.

Signed-off-by: Guillem Jover <guillem@hadrons.org>
---
 man2/futex.2        | 2 +-
 man4/random.4       | 2 +-
 man4/rtc.4          | 2 +-
 man5/proc.5         | 2 +-
 man7/capabilities.7 | 2 +-
 man7/hier.7         | 2 +-
 man7/rtld-audit.7   | 2 +-
 7 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/man2/futex.2 b/man2/futex.2
index 92eccde5b..eb4abac9e 100644
--- a/man2/futex.2
+++ b/man2/futex.2
@@ -1965,7 +1965,7 @@ Drepper, U., 2011. \fIFutexes Are Tricky\fP,
 .UR http://www.akkadia.org/drepper/futex.pdf
 .UE
 .PP
-Futex example library, futex-*.tar.bz2 at
+Futex example library, futex\-*.tar.bz2 at
 .br
 .UR https://mirrors.kernel.org\:/pub\:/linux\:/kernel\:/people\:/rusty/
 .UE
diff --git a/man4/random.4 b/man4/random.4
index 38396b667..edd047b77 100644
--- a/man4/random.4
+++ b/man4/random.4
@@ -265,7 +265,7 @@ These values can be changed by writing to the files.
 .TP
 .IR uuid " and " boot_id
 These read-only files
-contain random strings like 6fd5a44b-35f4-4ad4-a9b9-6b9be13e1fe9.
+contain random strings like 6fd5a44b\-35f4\-4ad4\-a9b9\-6b9be13e1fe9.
 The former is generated afresh for each read, the latter was
 generated once.
 .\"
diff --git a/man4/rtc.4 b/man4/rtc.4
index 55dc1ff6b..b16be16c1 100644
--- a/man4/rtc.4
+++ b/man4/rtc.4
@@ -43,7 +43,7 @@ and
 .BR time (2),
 as well as setting timestamps on files, and so on.
 The system clock reports seconds and microseconds since a start point,
-defined to be the POSIX Epoch: 1970-01-01 00:00:00 +0000 (UTC).
+defined to be the POSIX Epoch: 1970\-01\-01 00:00:00 +0000 (UTC).
 (One common implementation counts timer interrupts, once
 per "jiffy", at a frequency of 100, 250, or 1000 Hz.)
 That is, it is supposed to report wall clock time, which RTCs also do.
diff --git a/man5/proc.5 b/man5/proc.5
index dc5397a22..9c0b3e2ab 100644
--- a/man5/proc.5
+++ b/man5/proc.5
@@ -4383,7 +4383,7 @@ Unnumbered interrupts are not shown, only summed into the total.
 The number of context switches that the system underwent.
 .TP
 \fIbtime 769041601\fP
-boot time, in seconds since the Epoch, 1970-01-01 00:00:00 +0000 (UTC).
+boot time, in seconds since the Epoch, 1970\-01\-01 00:00:00 +0000 (UTC).
 .TP
 \fIprocesses 86031\fP
 Number of forks since boot.
diff --git a/man7/capabilities.7 b/man7/capabilities.7
index a9a676891..013efb0a5 100644
--- a/man7/capabilities.7
+++ b/man7/capabilities.7
@@ -1759,7 +1759,7 @@ capabilities and user namespaces, see
 .SH STANDARDS
 No standards govern capabilities, but the Linux capability implementation
 is based on the withdrawn
-.UR https://archive.org\:/details\:/posix_1003.1e-990310
+.UR https://archive.org\:/details\:/posix_1003.1e\-990310
 POSIX.1e draft standard
 .UE .
 .SH NOTES
diff --git a/man7/hier.7 b/man7/hier.7
index dc254c269..20a8a103b 100644
--- a/man7/hier.7
+++ b/man7/hier.7
@@ -273,7 +273,7 @@ and
 point at a random kernel tree.
 Debian systems don't do this
 and use headers from a known good kernel
-version, provided in the libc*-dev package.)
+version, provided in the libc*\-dev package.)
 .TP
 .I /usr/include/g++
 Include files to use with the GNU C++ compiler.
diff --git a/man7/rtld-audit.7 b/man7/rtld-audit.7
index c5d4fdddc..cc4b0431b 100644
--- a/man7/rtld-audit.7
+++ b/man7/rtld-audit.7
@@ -7,7 +7,7 @@
 .\"
 .TH RTLD-AUDIT 7 (date) "Linux man-pages (unreleased)"
 .SH NAME
-rtld-audit \- auditing API for the dynamic linker
+rtld\-audit \- auditing API for the dynamic linker
 .SH SYNOPSIS
 .nf
 .BR "#define _GNU_SOURCE" "             /* See feature_test_macros(7) */"
-- 
2.40.0

Re: [PATCH] man*/: ffix

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 2094 bytes --]

At 2023-04-17T01:19:16+0200, Guillem Jover wrote:
> Escape dashes on dates, UUIDs, URLs, file and package names.
[...]

I'm a +1 on all of this except the dates (explanation below).

> diff --git a/man4/rtc.4 b/man4/rtc.4
> index 55dc1ff6b..b16be16c1 100644
> --- a/man4/rtc.4
> +++ b/man4/rtc.4
> @@ -43,7 +43,7 @@ and
>  .BR time (2),
>  as well as setting timestamps on files, and so on.
>  The system clock reports seconds and microseconds since a start point,
> -defined to be the POSIX Epoch: 1970-01-01 00:00:00 +0000 (UTC).
> +defined to be the POSIX Epoch: 1970\-01\-01 00:00:00 +0000 (UTC).
>  (One common implementation counts timer interrupts, once
>  per "jiffy", at a frequency of 100, 250, or 1000 Hz.)
>  That is, it is supposed to report wall clock time, which RTCs also do.

> diff --git a/man5/proc.5 b/man5/proc.5
> index dc5397a22..9c0b3e2ab 100644
> --- a/man5/proc.5
> +++ b/man5/proc.5
> @@ -4383,7 +4383,7 @@ Unnumbered interrupts are not shown, only summed into the total.
>  The number of context switches that the system underwent.
>  .TP
>  \fIbtime 769041601\fP
> -boot time, in seconds since the Epoch, 1970-01-01 00:00:00 +0000 (UTC).
> +boot time, in seconds since the Epoch, 1970\-01\-01 00:00:00 +0000 (UTC).
>  .TP
>  \fIprocesses 86031\fP
>  Number of forks since boot.

These are parts of prose sentences and are themselves prose.  In the
groff man pages we neither model, nor recommend, the use of hyphen-minus
signs (escaped hyphens) in date strings, as one might commonly encounter
in `TH` calls to assign a revision date to a man page, for example.

Similarly, we would not escape the hyphen in the sentence: "While I was
in Quebec, I met Yves St-Denis.".[1]

Escaping hyphens is important for material that might copied and pasted.
I don't think these date expressions for the Epoch qualify.  If one
wants to format the date of the Epoch, "date --date=@0" is less to type.
(In a man page, we would escape _those_ hyphens and might bracket the
command with `EX` and `EE` macro calls.)

Regards,
Branden

[1] https://en.wikipedia.org/wiki/Yves_St-Denis

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] man*/: ffix

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 2841 bytes --]

Hi Branden, Guillem,

On 4/17/23 01:51, G. Branden Robinson wrote:
> At 2023-04-17T01:19:16+0200, Guillem Jover wrote:
>> Escape dashes on dates, UUIDs, URLs, file and package names.
> [...]
> 
> I'm a +1 on all of this except the dates (explanation below).
> 
>> diff --git a/man4/rtc.4 b/man4/rtc.4
>> index 55dc1ff6b..b16be16c1 100644
>> --- a/man4/rtc.4
>> +++ b/man4/rtc.4
>> @@ -43,7 +43,7 @@ and
>>  .BR time (2),
>>  as well as setting timestamps on files, and so on.
>>  The system clock reports seconds and microseconds since a start point,
>> -defined to be the POSIX Epoch: 1970-01-01 00:00:00 +0000 (UTC).
>> +defined to be the POSIX Epoch: 1970\-01\-01 00:00:00 +0000 (UTC).
>>  (One common implementation counts timer interrupts, once
>>  per "jiffy", at a frequency of 100, 250, or 1000 Hz.)
>>  That is, it is supposed to report wall clock time, which RTCs also do.
> 
>> diff --git a/man5/proc.5 b/man5/proc.5
>> index dc5397a22..9c0b3e2ab 100644
>> --- a/man5/proc.5
>> +++ b/man5/proc.5
>> @@ -4383,7 +4383,7 @@ Unnumbered interrupts are not shown, only summed into the total.
>>  The number of context switches that the system underwent.
>>  .TP
>>  \fIbtime 769041601\fP
>> -boot time, in seconds since the Epoch, 1970-01-01 00:00:00 +0000 (UTC).
>> +boot time, in seconds since the Epoch, 1970\-01\-01 00:00:00 +0000 (UTC).
>>  .TP
>>  \fIprocesses 86031\fP
>>  Number of forks since boot.
> 
> These are parts of prose sentences and are themselves prose.  In the
> groff man pages we neither model, nor recommend, the use of hyphen-minus
> signs (escaped hyphens) in date strings, as one might commonly encounter
> in `TH` calls to assign a revision date to a man page, for example.
> 
> Similarly, we would not escape the hyphen in the sentence: "While I was
> in Quebec, I met Yves St-Denis.".[1]
> 
> Escaping hyphens is important for material that might copied and pasted.
> I don't think these date expressions for the Epoch qualify.  If one
> wants to format the date of the Epoch, "date --date=@0" is less to type.
> (In a man page, we would escape _those_ hyphens and might bracket the
> command with `EX` and `EE` macro calls.)

What do standards say about formatting dates?  Do they specify the
character?  I read some RFCs, but didn't see it specified, other than
calling it literally '"-"'.  No name of the character, or ASCII code.

However, date(1) only accepts hyphen-minus, so it would be nice to use a
compatible format, even if standards didn't mandate it.

I'll hold the patch, to allow for some discussion, but I want to apply it.

Cheers,
Alex

> 
> Regards,
> Branden
> 
> [1] https://en.wikipedia.org/wiki/Yves_St-Denis

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] man*/: ffix

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 3632 bytes --]

Hi Alex,

At 2023-04-17T20:14:42+0200, Alejandro Colomar wrote:
> What do standards say about formatting dates?

Nothing that I know of.

> Do they specify the character?

Not that I know of.

> I read some RFCs, but didn't see it specified, other than calling it
> literally '"-"'.  No name of the character, or ASCII code.

Most RFCs don't concern themselves with typography.  :)

> However, date(1) only accepts hyphen-minus, so it would be nice to use
> a compatible format, even if standards didn't mandate it.

Sure, and for an example you actually intend someone to copy and paste,
you should _typeset it as an example_.

In my opinion, the cases at issue weren't examples of things to be
copied and pasted, but _read_.  That is why I attempted to point out a
much easier way of getting date(1) to format the Epoch.

As another example, in the history section of a man page, I might say
something like the following.

  This system call appeared in First Edition Unix, 1971-11-03.

It would be silly, in my opinion, to escape these hyphens.  They're not
intended as command parameters, but for the enlightenment of the reader.

I concede that there are people who don't _ever_ want to see proper
hyphens in UTF-8 man pages.  For them, _every_ hyphen should be a
hyphen-minus.  I don't agree, but groff man(7) can accommodate their
desires.  That is why groff has the following in its "PROBLEMS" file.

---snip---
[groff 1.19.2]

* When viewing man pages, some characters on my UTF-8 terminal emulator
  look funny or copy-and-paste wrong.  Why?

Some Unicode Basic Latin ("ASCII") input characters are mapped to
non-Basic Latin code points in output for consistency with other output
devices, like PDF.  See groff_man_style(7) and groff_char(7) for correct
input conventions and background.  If you use the correct groff special
character escape sequences to input them, you will get correct output no
matter what device the input is formatted for.

However, many man pages are written in ignorance of the correct special
characters to obtain the desired glyphs.  You can conceal these errors
by adding the following to your site-local man(7) configuration.  The
file is called "man.local"; its installation directory depends on how
groff was configured when it was built.

--- start ---
.if '\*[.T]'utf8' \{\
.  char ' \[aq]
.  char - \-
.  char ^ \[ha]
.  char ` \[ga]
.  char ~ \[ti]
.\}
--- end ---

You may also wish to do the same for "mdoc.local".

In man pages (only), groff maps the minus sign special character '\-' to
the Basic Latin hyphen-minus (U+002D) because man pages require this
glyph and there is no historically established *roff input character,
ordinary or special, for obtaining it when a hyphen and minus sign are
both separately available.  To obtain a true minus sign, use the special
character escape sequences '\(mi' or '\[mi]'.
---end snip---

By analogy, we don't compose man pages to write "don\[aq]t", even if for
some reason a person might want to type "don't" as input to a Unix
command.  (I hope they've prepared for its potential interaction with
the shell's quoting mechanisms.)  People have gradually realized over
the years that typing "don\[aq]t" is derpy and awkward.  Typesetting
enthusiasts also note that it gives you a wrongly-shaped apostrophe in
DVI, PostScript, and PDF output.

> I'll hold the patch, to allow for some discussion, but I want to apply
> it.

I unflinchingly agree with the remainder of the patch.  I simply want to
caution against a robotic process of demoting perfectly legitimate
hyphens to the crudely compromised hyphen-minus character.

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] man*/: ffix

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 3044 bytes --]

Hi Branden,

On 4/17/23 23:10, G. Branden Robinson wrote:
> Hi Alex,
> 
> At 2023-04-17T20:14:42+0200, Alejandro Colomar wrote:
>> What do standards say about formatting dates?
> 
> Nothing that I know of.
> 
>> Do they specify the character?
> 
> Not that I know of.
> 
>> I read some RFCs, but didn't see it specified, other than calling it
>> literally '"-"'.  No name of the character, or ASCII code.
> 
> Most RFCs don't concern themselves with typography.  :)
> 
>> However, date(1) only accepts hyphen-minus, so it would be nice to use
>> a compatible format, even if standards didn't mandate it.
> 
> Sure, and for an example you actually intend someone to copy and paste,
> you should _typeset it as an example_.
> 
> In my opinion, the cases at issue weren't examples of things to be
> copied and pasted, but _read_.  That is why I attempted to point out a
> much easier way of getting date(1) to format the Epoch.
> 
> As another example, in the history section of a man page, I might say
> something like the following.
> 
>   This system call appeared in First Edition Unix, 1971-11-03.
> 
> It would be silly, in my opinion, to escape these hyphens.  They're not
> intended as command parameters, but for the enlightenment of the reader.
> 
> I concede that there are people who don't _ever_ want to see proper
> hyphens in UTF-8 man pages.  For them, _every_ hyphen should be a
> hyphen-minus.  I don't agree, but groff man(7) can accommodate their
> desires.  That is why groff has the following in its "PROBLEMS" file.

You know I'm not one of those ;)

> 
> ---snip---
[...]
> ---end snip---
> 
> By analogy, we don't compose man pages to write "don\[aq]t", even if for
> some reason a person might want to type "don't" as input to a Unix
> command.  (I hope they've prepared for its potential interaction with
> the shell's quoting mechanisms.)  People have gradually realized over
> the years that typing "don\[aq]t" is derpy and awkward.  Typesetting
> enthusiasts also note that it gives you a wrongly-shaped apostrophe in
> DVI, PostScript, and PDF output.

I'm not convinced, because dates are not prose.  Why should we use hyphens
in dates formatted with standards-like formats?  I would agree in using
hyphens in dates if we spelled out dates unformatted, in plain English.
But if we use ISO-like or RFC-like formats, I think we should adhere to
them completely.

> 
>> I'll hold the patch, to allow for some discussion, but I want to apply
>> it.
> 
> I unflinchingly agree with the remainder of the patch.  I simply want to
> caution against a robotic process of demoting perfectly legitimate
> hyphens to the crudely compromised hyphen-minus character.

Please explain why they are reasonable there?  What's the use of a
hyphen in a date?  It's not a compound noun, or something like that.

Cheers,
Alex

> 
> Regards,
> Branden

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] man*/: ffix

[Lennart Jablonka]

Quoth Alejandro Colomar:
>>> What do standards say about formatting dates?
>>
>> Nothing that I know of.
>>
>>> Do they specify the character?
>>
>> Not that I know of.

ISO 8601:2004 (not the newest revision, but the one I found), the 
standard defining the YYYY‐MM‐DD explicitly calls for a “hyphen,” 
stating additionally:

>In an environment where use is made of a character repertoire based on 
>ISO/IEC 646, “hyphen” and “minus” are both mapped onto “hyphen-minus”.

This is not the case here.  A hyphen is the character to use; that is, 
an unescaped hyphen-minus in the input.

>> Most RFCs don't concern themselves with typography.  :)

RFCs usually tell you that they are talking about ASCII.

>>> However, date(1) only accepts hyphen-minus, so it would be nice to use
>>> a compatible format, even if standards didn't mandate it.

The standard mandates a hyphen.  A hyphen-minus is to be used where the 
date is to be interpreted as a string to be given to \fIdate\fP.

>> By analogy, we don't compose man pages to write "don\[aq]t", even if for
>> some reason a person might want to type "don't" as input to a Unix
>> command.  (I hope they've prepared for its potential interaction with
>> the shell's quoting mechanisms.)  People have gradually realized over
>> the years that typing "don\[aq]t" is derpy and awkward.  Typesetting
>> enthusiasts also note that it gives you a wrongly-shaped apostrophe in
>> DVI, PostScript, and PDF output.
>
>I'm not convinced, because dates are not prose.  Why should we use hyphens
>in dates formatted with standards-like formats?  I would agree in using
>hyphens in dates if we spelled out dates unformatted, in plain English.
>But if we use ISO-like or RFC-like formats, I think we should adhere to
>them completely.

Great!  Exactly my opinion.  An RFC usually tells you to use ASCII, so 
we should do that where applicable.  Luckily, we aren’t concerned with 
RFCs here, but with ISO 8601.

>> I unflinchingly agree with the remainder of the patch.  I simply want to
>> caution against a robotic process of demoting perfectly legitimate
>> hyphens to the crudely compromised hyphen-minus character.
>
>Please explain why they are reasonable there?  What's the use of a
>hyphen in a date?  It's not a compound noun, or something like that.

The use of a hyphen is that it is a character not used in date formats 
preceding ISO 8601.

Re: [PATCH] man*/: ffix

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 2060 bytes --]

Hi Lennart, Branden, and Guillem,

On 4/18/23 19:32, Lennart Jablonka wrote:
> Quoth Alejandro Colomar:
>>>> What do standards say about formatting dates?
>>>
>>> Nothing that I know of.
>>>
>>>> Do they specify the character?
>>>
>>> Not that I know of.
> 
> ISO 8601:2004 (not the newest revision, but the one I found), the 
> standard defining the YYYY‐MM‐DD explicitly calls for a “hyphen,” 
> stating additionally:
> 
>> In an environment where use is made of a character repertoire based on 
>> ISO/IEC 646, “hyphen” and “minus” are both mapped onto “hyphen-minus”.
> 
> This is not the case here.  A hyphen is the character to use; that is, 
> an unescaped hyphen-minus in the input.

Agreed.  Let's use hyphen for dates.  :)

Thanks for checking ISO!

[...]

>>>> However, date(1) only accepts hyphen-minus, so it would be nice to use
>>>> a compatible format, even if standards didn't mandate it.
> 
> The standard mandates a hyphen.  A hyphen-minus is to be used where the 
> date is to be interpreted as a string to be given to \fIdate\fP.

[...]

>> I'm not convinced, because dates are not prose.  Why should we use hyphens
>> in dates formatted with standards-like formats?  I would agree in using
>> hyphens in dates if we spelled out dates unformatted, in plain English.
>> But if we use ISO-like or RFC-like formats, I think we should adhere to
>> them completely.
> 
> Great!  Exactly my opinion.  An RFC usually tells you to use ASCII, so 
> we should do that where applicable.  Luckily, we aren’t concerned with 
> RFCs here, but with ISO 8601.
> 

Guillem, I'll apply your existing patch, and will remove manually the bits
about hyphen-minus.  You don't need to resend.

If you know about places where the man pages use hyphen-minus in dates and
would like to send a patch to remove the escape (so to produce a hyphen),
I'd appreciate that.

Cheers,
Alex

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] man*/: ffix

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 1412 bytes --]

Hi Alex,

At 2023-04-18T15:33:43+0200, Alejandro Colomar wrote:
> On 4/17/23 23:10, G. Branden Robinson wrote:
> > At 2023-04-17T20:14:42+0200, Alejandro Colomar wrote:
> >> What do standards say about formatting dates?
> > 
> > Nothing that I know of.

At 2023-04-18T17:32:01+0000, Lennart Jablonka wrote:
> ISO 8601:2004 (not the newest revision, but the one I found), the
> standard defining the YYYY‐MM‐DD explicitly calls for a “hyphen,”
> stating additionally:
> 
> > In an environment where use is made of a character repertoire based
> > on ISO/IEC 646, “hyphen” and “minus” are both mapped onto
> > “hyphen-minus”.
> 
> This is not the case here.  A hyphen is the character to use; that is,
> an unescaped hyphen-minus in the input.

I thank Lennart for having a standards doc to brandish when I did not.

I'll see if I can scare up a copy of ISO 8601.  It's a shame so many
standards docs are not open-access.

There is only one point I want to further pursue.

> I'm not convinced, because dates are not prose.

A character sequence's status as prose is determined by context, not
content.

who am i

is prose (if somewhat substandard English) in some contexts, and a Unix
shell command in others.

Or it might be part of an e. e. cummings poem.

We cannot solve all of our man page formatting problems with sed, alas.

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] man*/: ffix

[Guillem Jover]

Hi!

On Mon, 2023-04-17 at 20:14:42 +0200, Alejandro Colomar wrote:
> On 4/17/23 01:51, G. Branden Robinson wrote:
> > At 2023-04-17T01:19:16+0200, Guillem Jover wrote:
> >> Escape dashes on dates, UUIDs, URLs, file and package names.
> > [...]
> > 
> > I'm a +1 on all of this except the dates (explanation below).
> > 
> >> diff --git a/man4/rtc.4 b/man4/rtc.4
> >> index 55dc1ff6b..b16be16c1 100644
> >> --- a/man4/rtc.4
> >> +++ b/man4/rtc.4
> >> @@ -43,7 +43,7 @@ and
> >>  .BR time (2),
> >>  as well as setting timestamps on files, and so on.
> >>  The system clock reports seconds and microseconds since a start point,
> >> -defined to be the POSIX Epoch: 1970-01-01 00:00:00 +0000 (UTC).
> >> +defined to be the POSIX Epoch: 1970\-01\-01 00:00:00 +0000 (UTC).
> >>  (One common implementation counts timer interrupts, once
> >>  per "jiffy", at a frequency of 100, 250, or 1000 Hz.)
> >>  That is, it is supposed to report wall clock time, which RTCs also do.
> > 
> >> diff --git a/man5/proc.5 b/man5/proc.5
> >> index dc5397a22..9c0b3e2ab 100644
> >> --- a/man5/proc.5
> >> +++ b/man5/proc.5
> >> @@ -4383,7 +4383,7 @@ Unnumbered interrupts are not shown, only summed into the total.
> >>  The number of context switches that the system underwent.
> >>  .TP
> >>  \fIbtime 769041601\fP
> >> -boot time, in seconds since the Epoch, 1970-01-01 00:00:00 +0000 (UTC).
> >> +boot time, in seconds since the Epoch, 1970\-01\-01 00:00:00 +0000 (UTC).
> >>  .TP
> >>  \fIprocesses 86031\fP
> >>  Number of forks since boot.
> > 
> > These are parts of prose sentences and are themselves prose.  In the
> > groff man pages we neither model, nor recommend, the use of hyphen-minus
> > signs (escaped hyphens) in date strings, as one might commonly encounter
> > in `TH` calls to assign a revision date to a man page, for example.

AFAIR at the time I escaped these because they looked parseable dates,
pretty close to ISO 8601. And there is at least escaped versions of
the epoch in getspnam.3. But rechecking now it seems there are many
other instances of the same string, so these were perhaps newer than
my initial change, or I missed them at the time.

> > Similarly, we would not escape the hyphen in the sentence: "While I was
> > in Quebec, I met Yves St-Denis.".[1]

Sure, but I don't find these comparable. :)

> What do standards say about formatting dates?  Do they specify the
> character?  I read some RFCs, but didn't see it specified, other than
> calling it literally '"-"'.  No name of the character, or ASCII code.
> 
> However, date(1) only accepts hyphen-minus, so it would be nice to use a
> compatible format, even if standards didn't mandate it.
> 
> I'll hold the patch, to allow for some discussion, but I want to apply it.

In any case, while it's true that there are easier ways to get the epoch,
these still look like things that could end up being parsed? So my
instinct would be to escape them, but I don't think I care much either
way, so I'm happy to revert that patch and resend (or feel free to do
that yourself), or update all the other instances which I missed and
resend.

Thanks,
Guillem