Hi Ingo, At 2026-01-21T19:28:13+0100, Ingo Schwarze wrote: > G. Branden Robinson wrote on Mon, Jan 19, 2026 at 11:29:49AM -0600: > > After all, the date isn't part of the formatter interface either, so > > why do we have the crap below? > > > > $ nroff -t -man -P -cbou $(man -w 'groff(7)') \ > > | grep -E '\n\[(year|yr|mo|dy|dw|hours|minutes|seconds)]' > > \n[dw] Day of the week (1–7; 1 is Sunday). > > \n[dy] Day of the month (1–31). > > \n[hours] Count of hours elapsed since midnight (0–23). > > \n[minutes] Count of minutes elapsed in the hour (0–59). > > \n[mo] Month of the year (1–12). > > \n[seconds] Count of seconds elapsed in the minute (0–60). > > \n[year] Gregorian year. > > \n[yr] Gregorian year minus 1900. > > I agree, none of that is valuable.
Alas for our concurrence, I was being facetious. I think the foregoing
are fine, when considering groff as applied to its entire mission as
opposed to merely a man page formatter.
> In manual pages, using these is clearly detrimental. The content of
> documentation should not depend on the date or time of formatting.
> If anything, only the date and time of the software being documented
> or the last update of the documentation should be mentioned.
I wouldn't proclaim this as an iron-clad rule--maybe a 95% one.
I _definitely_ think man pages should record their date of most recent
revision by a human in a `TH` (man(7)) or `Dd` (mdoc(7)) macro call.
People who fail to do that should be flogged.
> For documents that are not manual pages, making a case for such
> registers is slightly easier - but even there, i claim that using
> them is detrimental more often than useful. For example, how often
> have i looked at business letter documents written by others and
> went "wait, what? this clearly wasn't written *today*. So, when
> was this written and sent out? Let's look at the file modification
> date. Oh, that can't be right either - apparently someone modified it
> after the fact or copied it around." Wouln't it be great if you
> could find the real date of a real letter by the author actually
> putting that date into the file, rather then putting a macro there
> that will start lying the very next day?
I'm afraid I have little insight in to why Ossanna troff (nroff even?)
supported `yr`, `mo`, `dy`, and `dw` registers. Common practice even in
the mid-1970s appeared to be to use ms's `ND` macro to declare a
document's revision date explicitly.
However, I have a theory.
groff_ms(7):
Differences from AT&T ms
...
• groff ms uses the same header and footer defaults in both
nroff and troff modes as AT&T ms does in troff mode; AT&T’s
default in nroff mode is to put the date, in U.S. traditional
format (e.g., “January 1, 2021”), in the center footer (the CF
string).
...
...and, if you didn't specify a date yourself, the macro package would
construct one--_using the aforementioned registers_.
In Sixth Edition Unix ms (1975),[1] we see:
.ds DY \*(mo \n(dy, 19\n(yr
...and...
.if n .ds CF "\\*(DY
. DA - force date; ND - no date or new date.
.de DA
.if \\n(.$ .ds DY \\$1 \\$2 \\$3 \\$4
.ds CF \\*(DY
..
.de ND
.ds DY \\$1 \\$2 \\$3 \\$4
.rm CF
..
...and some logic mapping month numbers to their English names.
To surmise why the current made any sense as an nroff-mode default, I
think we need to imagine the working environment of the Bell Labs CSRC.
What did you use for a terminal?
A Teletype machine.
You didn't work a computer screen or even a dumb terminal with a
monochrome, text-only 80x24[2] video display. You worked at a
typewriter that wrote to continuous-feed rolls of paper. You know what
humans are like. People who ran nroff with any frequency likely had
heaps of printed-on, uncut paper piling up and, if they ever had to go
back through it to find some, as we so often do with "scrollback
buffers", it would be easy to be uncertain about when a copy of a
document was formatted.[3] The CSRC didn't originally use revision
control, either, remember--that had to wait for Rochkind over in the USG
department or wherever to write SCCS.
> Instead, use the system package manager to find out which versions of
> software you are running, and use date(1) to find out what time it is.
Except that, in groff, for sound reasons, these require "unsafe mode".
> [...]
> > So, unlike you, I don't need smelling salts to cope with `\n[.Y]`.
> > But it should be used only advisedly.
>
> Yeah, kind of. Anyway, trying to kill it now would likely cause minor
> trouble for almost no benefit.
I learned the other day that \n[.Y] wasn't originally in groff.
NEWS:
VERSION 1.16
============
...
A new read-only register, `.Y', has been added. It contains the
revision number of the groff package.
...
ChangeLog.116:
...
Version 1.16 released 2000-05-23
...
> I think what we should have right nor is:
>
> \n[.x] 1
> \n[.y] 24
> \n[.Y] 0
$ printf '.nf\nx=\\n[.x]\ny=\\n[.y]\nY=\\n[.Y]\n.fi' | ./build/test-groff -a
<beginning of page>
x=1
y=24
Y=0
> extraction directory name groff-1.24.0 or groff-1.24.0rc1,
> whichever you like better
> tarball name groff-1.24.0rc1.tar.gz
It'll be groff-1.24.0.rc1 for consistency with past release candidates.
See <https://alpha.gnu.org/gnu/groff/>.
$ tar tfz groff-1.22.4.rc5.tar.gz |head -n 1
groff-1.22.4.rc5/
$ tar tfz groff-1.23.0.rc4.tar.gz |head -n 1
groff-1.23.0.rc4/
> Of course, such automation can be overengineered, but i'm neither
> claiming what Bertrand did is overengineered nor that it is simple.
It seems fine. Colin and you caught one mistake[4] and I made a bigger
one myself (renaming the dist archive, uploading that, and tagging the
RC only in retrospect).
> I'm still quite far away from getting groff-1.24.0rc1 to build, let
> alone run, so i can't answer that just yet.
I'll be on tenterhooks...
> Nonono, i consider calling 1.24.0 a "version number" reasonable
> enough. Nobody, not even a die-hard algebraist, is calling that a
> "version module element" because of
> https://en.wikipedia.org/wiki/Module_(mathematics)
If anyone ever wants to pry me away from groff maintainership, all they
have to do is fully sponsor me to go back to school full time and get a
degree in math. I need real analysis. I need complex analysis. I need
"modern" algebra. I need topology. I need category theory. I need
numerical methods. And I want to read everything Coxeter ever wrote,
because his field seems simultaneously familiar and alien.
Regards,
Branden
[1] https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/lib/tmac.s
[2] If your 1975 organization jumped on the CRT terminal bandwagon but
was cheap about it, you acquired DEC VT50s--the half-brained cousins
of DEC VT52s, capable only of an 80x12 display. (I presume this was
because solid-state memory was so expensive.)
[3] I wonder why people didn't just put the date and/or time into their
shell prompts. Maybe you couldn't with the Mashey shell. (The
Bourne shell hadn't been written yet in 1975.) Or maybe even if you
could, maybe few would have had the patience to wait for a shell
prompt that lengthy to type out. The line speed of a Teletype Model
37, the Ferrari of Teletype machines, was 150 bits per second. The
slowest I've ever experienced was 300 bits per second, which I think
is slow enough to promote suicidal ideation in users. Everybody
hates waiting on the shell to be ready for input. *It* is supposed
to wait for *us*. Some things, I reckon, have not changed at all
since 1975.
[4] (from my working copy)
commit 9fdb52a9cc805d7d5d42895e5a71b72d64e78e38
Author: G. Branden Robinson <[email protected]>
Date: Mon Jan 19 12:24:25 2026 -0600
Makefile.am: Clean up distribution archive.
* Makefile.am: Stop adding ".version" file to the `EXTRA_DIST` and
`BUILT_SOURCES` macros.
Fixes <https://savannah.gnu.org/bugs/?67927>. Thanks to Colin Watson
for the report.
signature.asc
Description: PGP signature
