Hello,
"Sebastien Vauban"
<wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org> writes:
> Speaking of hyperref and its _document properties_, it makes me think of a
> generic point for which I don't have yet a really satisfactory solution, that
> is about handling dates.
>
> In a PDF document, regarding dates, we have (see output of `pdfinfo'):
>
> - creation date
> - modification date
>
> In Org, we have the `#+DATE:' info keyword, with the date that's supposed to
> be exported onto the final document format (HTML, PDF, OOo, etc.).
>
> But we don't see when the document has been updated for the last time --
> neither when it has been created.
>
> For the former point (date of last update), I've customized Org so that the
> `time-stamp' package updates time stamps every time you save the Org buffer:
>
> #+begin_src emacs-lisp
> (add-hook 'before-save-hook 'time-stamp)
>
> (add-hook 'org-mode-hook
> (lambda ()
> ;; file modification date
> (set (make-local-variable 'time-stamp-format) "%:y-%02m-%02d")
> (set (make-local-variable 'time-stamp-start) "^#\\+DATE: +")
> (set (make-local-variable 'time-stamp-end) "$")))
> #+end_src
>
> That makes my `#+DATE:' info keyword always *up-to-date*.
>
> Though, in some cases:
>
> - I must print a document with a future date (for example, I'm preparing
> slides which I will present on next Monday) -- hence, the above breaks this,
> because I'd like to have next Monday's date already printed on my slides (at
> least on the title page).
>
> - it would be nice to get keep track of the creation date of the Org document,
> though this is not really necessary.
>
> Clearly, I should not make the `#+DATE:' info keyword updated, to keep it for
> its export function (as the official date to be printed on the title page),
> but then it'd be good to have at least a last modification date
> somewhere.
>
> What do you think of all this? How do you do to keep more info on
> dates?
Export systems already provide a {{{modification-time(format-string)}}}
macro by default.
> Some global `draft' or `final' info could make some sense too.
Isn't it too much back-end specific?
Regards,
--
Nicolas Goaziou
