Markdown metadata for `date` field is all in 1970

[stefmolin]

I just noticed that the date field in the metadata for several Markdown files (for example tutorials/publish-conda-forge.md) states they were written in 1970. It looks like these were introduced in #488.

[stefmolin]

For my website, I use a tool in my GitHub Actions workflow to restore the modified time to my post Markdown files so that the RSS feed always has the true last modified time:

- name: Checkout
  uses: actions/checkout@v4
  with:
    fetch-depth: 0  # need to fetch all commits for git restore-mtime

- name: Restore timestamps
  run: sudo apt-get install git-restore-mtime && git restore-mtime

Then, you can remove this field from the metadata of each file, and in Python, you can do Path(file).stat().st_mtime to grab the timestamp for your RSS feed (see https://docs.python.org/3/library/pathlib.html#pathlib.Path.stat).

[ucodery]

Pinging @sneakers-the-rat. This is odd, but it looks like the frontmatter you added got some generated dates? It looks to me like it was something akin to date.fromtimestamp(0) + file_enumeration_index. I don't see anything like that in your PR, but it might have been a script you used before commit?

[sneakers-the-rat]

Lol no those were just placeholder dates intended to be replaced with actual dates

I dont think I changed the mtime, but this would probably do it: https://github.com/pyOpenSci/python-package-guide/pull/488/files#diff-77763db26eb3ad9b3f8b8b9104c9ec0b97bbc5d264f644f811803ca1381616a1R4

[lwasser]

@sneakers-the-rat did the hard work! I went in and added the titles and descriptions to each file. ❤ @stefmolin suggested a better way to do things that updates our rss feed automagically using bash during our sprint :)

So I think our next step is to implement the CI action, and delete the existing date front matter "field". And then we will have a last modified date that automagically updates as we commit changes to each lesson.

UNRELATED TO THIS THREAD (but related to the big picture): @banesullivan this also relates to the work you're doing on the website side of things. I think we should use the rss feed for this reason!!

[sneakers-the-rat]

hell ya. i have found that i pretty much always want to have an explicit "date created" and an automatic "date updated" when i do bloglike things, but that's also because i fiddle with my documents all the time and am very indecisive about when i call things "done." <3. (up to you obvi)

i had thought about adding this when i wrote it, but i think it might be somewhat durable to do that in the extension build action by inspecting mtime since you have the metadata and the file object together there when you're rendering the feed anyway. were you thinking a git commit hook or something?

[lwasser]

Nice! I have no specific preference about how we implement this! I haven't worked with git hooks other than pre-commit but if it quietly updates the last_updated date when people commit, with no setup, let's do it. If there is setup for a dev to do with the hook, then we might want to have it be fully CI-driven with a local option to test. I'm open to what y'all think is best practice.

Funny timing. I just found this extension today. I wanted to add the last commit date to every rendered page in our handbook, given it has governance stuff, and I want to be transparent. If you look at the bottom of the handbook page, it automagically adds a last updated date to each page using the git history.

And all I had to do was create a little Jinja template with {{ last_updated }} to make it render. I'm not sure, however, if that value can be injected somehow into a custom feed. I just wanted to highlight the coolness in case it was useful. (It's been updated in the past few weeks, even though PyPI suggests it hasn't been released in a while.)

[sneakers-the-rat]

I guess the way I would do it is to not have it stored statically in the page metadata at all, but just read from mtime when the site is built? That would be one or two lines.

But if you are already using something that does that, then might as well be consistent. No strong feelings either.

[lwasser]

I'm all for grabbing the date from the metadata!! Let's do that.

So now we need to decide on the approach. Stef's comment above looks clean and simple! Since I don't yet understand how to incorporate the last_updated metadata into the generated feed, I'll rely on your judgment.

The extension I found has a good bit of code. If the extension makes things easier, we could use it. But given how simple Stef's example above is, maybe that is the clean way to do things?

In short, I feel like I don't know enough here to make a call. But simpler seems most often better :)

[sneakers-the-rat]

Stef and I are thinking of the same thing! i can draft this, one sec

[lwasser]

Thank you!!