bug#32931: time-stamp-format: offer numeric time zones too

[Stephen Gildea]

Eli, I would like to introduce this feature to time-stamp the same way
I have introduced other features: implement first, document later.
Implement in this release, document in a later release.

For example, the conversion "%q" (unqualified hostname) will be
new in Emacs 27.  It is newly described in the doc string of
time-stamp-format.  It is mentioned in 27.1 NEWS.  But the only
new thing is the documentation; a key point is that the feature
works in Emacs 26, too.  You can try it now:
(progn (require 'time-stamp) (time-stamp-string "%q"))

So why all this care with the timing of the time-stamp documentation?

Compatibility is difficult for time-stamp because people can set
time-stamp-pattern/time-stamp-format in their files.  This captures
the current protocol, and these user files have to be considered when
making any change to the time-stamp implementation or documentation.
When someone sets time-stamp-pattern/time-stamp-format as a local
variable, they are relying on a promise that the next time Emacs
(any Emacs) reads that file, the setting will be honored still.

Imagine that I don't do it this way, and a user sees a new feature.
(Perhaps the new feature is accompanied by a compatibility warning, but
the user thinks, "I use only my laptop, which I just upgraded to Emacs
27.1, so this is okay.")  They use the new feature in a local-variable
setting in their files.  Time passes, and they forget they have used
this new feature.  They give the file to a friend, or they edit it
from their work laptop, or they distribute the file on their git
repository.  By one of these paths, the file ends up getting edited
with a different Emacs, say version 24.5.  When that old Emacs saves
the file, it gets corrupted.

Given all the above, are you sure we want to document this now?

 < Stephen