-
Notifications
You must be signed in to change notification settings - Fork 4
File modification times
To have a date at the top of every page that reflects when that individual page was modified - not when it was rendered. It is easy in Quarto to add a date, but every way that was tried has the same date on every page.
- Date Formatting
- In the Title Block
- On HTML Pages i.e. in
_quarto.yml
This is possible. You can include R code that refers to any file in the repo and it will return the modification time for that specific file. So something like this will give 2 dates (albeit with a crazy decimal number for seconds)
---
title: "Data Portal"
subtitle: "Download the Data Used in the Report's Figures"
date-format: "MMM D, YYYY [at] HH:mm z"
params:
qmd_file: "data.qmd"
db_file: "data/working/aetr.db"
...
\```{r, echo=FALSE,warning=FALSE,message=FALSE}
\```
This page last modified: `r file.info(params$qmd_file)$mtime`
Database file last modified: `r file.info(params$db_file)$mtime`
The GitHub actions part of the repo (the workflow) changes the modification time of the file. "Git stores the last modification time for each file, based on its commit history" not the local modification time. That means when the workflow checks out the repository, it uses that time as the file modification time, which throws off Quarto's render. For git, this is a feature not a bug. This is so that any source code builds with make will be triggered for all the files. There are lots of work-around to be found by googling but they rely on other packages or are platform specific.
More notes
- Ur StackOverflow
- An old git wiki describing modification times.
This has been noted in the context of Quarto. For instance this fix was offered in response to this issue. However, that fix didn't work in our context. It bombs completely in MacOS with because MacOS doesn't like the argument to date. In the repo, it changed the file modification time to the commit time, but that time is still the same for all the files.
Here is a pre-commit hook that changes an HTML tag in the code with a sed command. And here is another pre-commit hook that does the same to a markdown file in the context of Jekyll. The latter seems like it would work pretty well in the context of Quarto. However, it still ties the modification date to the git commit time in a rigid way.
Adding last modified timestamps to content describes the problem in the context of blog pages. He ended up hard-coding it. His reasoning is that "What readers expect when viewing the last-modified tag is the date when the content was last edited in some marginally significant way." so he didn't want it triggered for minor changes like typo fixes.
We accepted the reasoning that justifies hard coding the date in the file. It might be more laborious to maintain, but it will be a more accurate representation of when major changes occur as opposed potentially tiny git commits.
So as of 4/1/2024, every page has 2 dates: Published which is generated by Quarto/GitHub when it is rendered, and Modified which is hardcoded in the front matter of each .qmd file individually. The latter can be used to indicate if the data files change, or the plots, or some major bit of text revision. Modified should not be edited for typo fixes or formatting adjustments.