💾 Archived View for siiky.srht.site › meta › dates.gmi captured on 2024-08-18 at 17:52:42. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Post dates

siiky

2022/06/23

2022/08/03

Until now, I'd never "standardized" what the dates on my site mean, even though I've been consistent with them everywhere (not much to screw up anyway): both on the index and the posts themselves, the dates are always when I started writing the post (or created the file, at least). So there are unfinished (unstarted, even) posts that, were I to finish and publish, would get the date I first created them on the index. This isn't great. And something similarly ungreat happens with posts that I take a long time to write (actually actively writing), sometimes across a few days of a week -- the post has a certain date, but in reality it's published only some days later -- usually leading to interleaving of posts: start post A, start post B, publish post B, publish post A.

I started thinking about this because I've been lurking Geminispace for a bit now, and liking it a lot! So I'm planning on writing in Gemtext from now on, instead of Markdown or Org, and convert my site to a Gemini capsule (still making HTML available through HTTPS for anyone not with it <insert Dr. Evil reference here>). Turning the index, which is one of the most complex parts of my site, into a simple Gemtext page, is just... hmhmhm! And, other than the index being the front-page, serving at the same time as the "feed" that people can subscribe to is also just... hmhmhm!

But with that comes a problem, because I update posts, some more than others, some days more than others, but, posts don't necessarily remain as they were first published. Because of it, and of the interleaving I mentioned above, I'll start using a new convention -- slightly harder to maintain, but if I don't screw up should be worth it:

Posts themselves will have the date of when I first started writing or first created the file, while the index (feed) will have the date of the last update instead. This way should give no jumps to the past when I publish new posts, and at the same time works as an updates notifier (though I still have to test how clients behave).