When I designed DWiki back in the mists of time, I decided that it would not require any writable data store (and certainly not an actual database, because that would have required me to configure and run one); I wanted to be able to run it completely read-only, so I could worry less about its security implications. I also decided that it should not have explicit metadata embedded in page data, which are all in regular text files.

Blog entries have one primary time associated with them, their publication date; Atom feed entries have two times associated with them, their original publication date and their most recent (significant) update. Normally you drive these from entry metadata, or if the user doesn't supply it you keep track of it internally, but DWiki doesn't have either of those options.

With very few sources of entry timestamps, DWiki has to use the Unix file modification time of the file for the entry's page as a blog entry's publication date. This leaves it short of an Atom last updated time; the only even vaguely sensible choice is the file 'inode change time', which updates any time you sneeze on the file. Unfortunately this means that the last updated time may change when there was no actual update because something touched the file in a way that changed the file ctime, but things usually work out because this is pretty rare.

(I cannot drop the last updated time entirely because it is mandatory for Atom feed entries; I cannot make it the same as the original publication date without it sometimes being a lie.)

The big drawback for all of this came up last Tuesday, when this server was migrated to new hardware (running a different OS), complete with copying all of our files over. This updated the ctime on all of my files to right then, when they were restored on the new machine, which promptly 'updated' every entry in my Atom feed to right then (with peculiar consequences for at least the LiveJournal feed, which scrambled the entry order and as a result reran some old entries).

Sidebar: post-publication editing of entries

One inconvenience of this collection of design choices is that if I edit an entry after publication, I have to carefully reset its file mtime afterwards (I have a script for this). This is part of why the file ctime has to be the last updated time, because it is the only timestamp that changes when I do this.

Fortunately I rarely feel the urge (or have the need) to edit entries after publication. Arguably this is a good thing.