1 I'm having a hard time figuring out how the creation time, modification time, internal `ctime` and `mtime` fields (in `indexdb`) play along with the [[plugins/meta]] directive.
3 In some articles I write, I hardcode the creation and modification time, because they are imported from LWN.net, as such:
5 \[[!meta title="The cost of hosting in the cloud"]]
6 \[[!meta date="2018-02-281T12:00:00-0500"]]
7 \[[!meta updated="2018-03-12T14:22:45-0500"]]
9 But strangely, [that article](https://anarc.at/blog/2018-03-12-cost-of-hosting/) does *not* show up as "created" on "february 28th": it shows up as "Created 6 days and 20 hours ago", ie. "march 12th" (`2018-03-12T18:29:12Z`). That is strange, because that's the *modification* date (`meta updated`), not the *creation* date. Similarly, the "edited" date is `2018-03-19T14:47:45Z` (40 minutes ago), which is more or less accurate: the page *was* modified some time ago, but shouldn't the `meta` tag override that? Note that the `edited` date matches the file's `mtime` field in the source directory:
11 w-anarcat@marcos:~$ LANG=C stat source/blog/2018-03-12-cost-of-hosting.mdwn
12 File: source/blog/2018-03-12-cost-of-hosting.mdwn
13 Size: 14022 Blocks: 32 IO Block: 4096 regular file
14 Device: fd05h/64773d Inode: 7905532 Links: 1
15 Access: (0644/-rw-r--r--) Uid: ( 1026/w-anarcat) Gid: ( 1026/w-anarcat)
16 Access: 2018-03-19 11:19:21.237074935 -0400
17 Modify: 2018-03-19 10:47:45.000000000 -0400
18 Change: 2018-03-19 11:19:20.509065456 -0400
21 This wouldn't be so much of a problem if that stuff was consistent: but it's not really. What's supposed to be the [following article](https://anarc.at/blog/2018-03-19-sigal/) actually shows up *before* in the [blog index](https://anarc.at/blog/) which is rather annoying. It's also [backwards in the RSS feed](https://anarc.at/blog/index.rss), which will possibly break some feed readers who will miss the new article.
23 That newer article shows up as `Created 12 days and 15 hours ago` (`2018-03-07T00:00:00Z`) and also "edited 40 minutes ago" (`2018-03-19T14:51:29Z`). It has the following meta:
25 \[[!meta title="Easy photo galleries with Sigal"]]
26 \[[!meta date="2018-03-07T00:00:00+0000"]]
27 \[[!meta updated="2018-03-19T10:26:12-0400"]]
29 So *there* the `date` meta tag *works*: the creation date is correct, but obviously, it means it comes *before* the other article, because *that* one doesn't get loaded correctly.
31 By now, clever folks will have noticed the problem: it's with the first timestamp:
33 \[[!meta date="2018-02-281T12:00:00-0500"]]
35 There's an extra one in there! Obviously, february 281 is not a valid date... What happened is that I sometimes modify those dates by hand, and I sometimes mess it up. I actually messed it up twice there, the original timestamps were:
37 \[[!meta date="2018-02-281T12:00:00-0500"]]
38 \[[!meta updated="2018-14-22T14:22:45-0500"]]
40 The error, in the second one, is that I put the time instead of the date (!). I must have been very distracted, but still it's kind of hard to edit those timestamps correctly. I think the fundamental problem here is that Ikiwiki doesn't say anything when those timestamps can't be parsed properly. It seems to me there should be an error somewhere, if not directly in the page, at least in the rendering logs or somewhere, if the date cannot be parsed correctly.
42 So, long story short: shouldn't invalid dates in meta tags yield an error of some sort instead of being silently ignored? I spent half an hour figuring this one out, going as far as regenerating the whole wiki to try and see if it was a caching issue in indexdb...
48 > If you're reporting a bug, it would be helpful to lead with the actual bug and save
49 > the account of how you tried to debug it for later (or omit it).
50 > I've moved this from a forum post into a bug report.
52 > The meta plugin uses Date::Parse::str2time from the TimeDate Perl library, so it has
53 > whatever error handling that has. However, historically any error has essentially
54 > been ignored, which I think is a bug.
56 > `\[[!meta date]]` and `\[[!meta updated]]` have two purposes:
58 > * they create `<meta name="date" content="xxx">` and `<meta name="updated" content="xxx">`
59 > * they change the ctime/mtime used by ikiwiki for sorting, etc.
61 > I think the historical assumption was that even if the date can't be parsed for the
62 > second purpose, you still want the first purpose. However, you're right that this is
63 > really fragile, and the first purpose seems fairly niche anyway.
64 > In ikiwiki git master (to be released as 3.20180321 or later) I've made `\[[!meta date=...]]`
65 > and `\[[!meta updated=...]]`
66 > produce an error message if you don't have `Date::Parse` or if the date/time is
69 > In the unlikely event that someone really wants `<meta name="date" content="xxx">`
70 > without parsing the date, they can still use `\[[!meta name="date" content="xxx"]]`.
72 > [[!tag done]] --[[smcv]]
74 > > To my defense, when I wrote this, I didn't consider this a bug: I
75 > > was assuming the problem I was seeing was just some dumb mistake
76 > > that I made and, indeed, there *was* one such formatting mistake.
78 > > But yeah, I could have re-edited this whole thing to make it look
79 > > better. I'm sorry, but I was at the end of an already long
80 > > yak-shaving session...
82 > > I wasn't sure if doing an error was the right way to go, as this
83 > > might break rendering for existing sites... But I'm glad you fixed
86 > > Thank you for the super-fast-response! :) I also tried updating
87 > > the [[meta directive documentation|ikiwiki/directive/meta]] so
88 > > that it's a little more detailed about that stuff. I hope that's
89 > > alright... -- [[anarcat]]