This is supported nowadays via grml-live's -d option:

% grml-live --help | grep -- -d
   -d <date>               use specified date instead of build time as date of
release

In our current release workflow we have a basic Jenkins job like
"grml64-small_testing" which runs on a daily base and whenever we set "Keep this
build forever" for a specific build we can use this jobs artifacts for the
according release job ("grml64-small_Release").

Now we have the "Do not update chroot" option available in our grml-live Jenkins
plugin. When *disabled* we run this command line:

  sudo -A grml-live -F -V -A -a amd64 -c
DEBORPHAN,GRMLBASE,GRML_SMALL,RELEASE,AMD64,IGNORE,SNAPSHOT -s testing \
    -e grml*.iso -U jenkins -v 2014.03-rc1 -r Ponywagon -g grml64-small -o
/var/lib/jenkins/jobs/grml64-small_Release/workspace

while when it's *enabled* we run this command line (notice the "-b"):

  sudo -A grml-live -F -V -A -a amd64 -c
DEBORPHAN,GRMLBASE,GRML_SMALL,RELEASE,AMD64,IGNORE,SNAPSHOT -s testing -b \
    -e grml*.iso -U jenkins -v 2014.03-rc1 -r Ponywagon -g grml64-small -o
/var/lib/jenkins/jobs/grml64-small_Release/workspace

It would be nice if we could (re)produce a Grml ISO for a specific date,
speaking in terms of official Debian packages (the Grml ones aren't that
important since we control the repository on our own). So instead of using e.g.
Debian's jessie distribution as-is on the day of stable release build we could
use the packages from the day when we built the latest release candidate.

The grml-live part shouldn't be a big deal (famous last words), proper
integration into Jenkins might be trickier though (esp. given that the
ruby-runtime seems to be unmaintained ->
https://issues.jenkins-ci.org/browse/JENKINS-18838).