Minutes are presented as the day of the month

Hosting on Micro.blog
1

So I noticed an interesting issue on my blog… The post’s published date is shown as the day, followed by hours and minutes (24 hrs format), but instead of minutes, it shows the day of the month again.

So a post from today at 6 PM will show as 2023-08-09 @ 18:09, a post an hour from then at 7 PM would be 2023-08-09 @ 19:09, and a post tomorrow at 11:22 AM (or 11: 35, it doesn’t matter) will show as 2023-08-10 @ 11:10. The post itself (not the published HTML) does show the right timestamp. This makes me think I screwed up something in my theme, but I’m not sure what. Here are the relevant parts (I think):

layouts/post/single.html:

<time class="dt-published" datetime="{{ .Date.Format "2006-01-02 15:04:05 -0700" }}">
        <a class="u-url dates" href="{{ .Permalink }}">{{ .Date.Format "2006-01-02 @ 15:02" }}</a>

layouts/partials/post-item.html

<time datetime="{{ .Date.Format "2006-01-02 15:04:05 -0700" }}" class="dt-published">→{{ .Date.Format "2006-01-02 @ 15:02" }}</time>
2

I don’t think you can use an @ symbol in there like that. You can inspect the page on your site to see if the time has a datetime value that does not have the @ and it is correct to check.

3

Hmmm… I was playing around with it this morning, and when I removed the “@” it worked, but then when I put it back it worked just as well. This made me think I just posted the code wrong somewhere.

I think it’s fixed, here’s what I have for post-item.html now:

<time datetime="{{ .Date.Format "2006-01-02 15:04" }}" class="dt-published" > →{{ .Date.Format "2006-01-02 @ 15:04" }} </time>

I think the problem was that the datetime part did not match the published part. That is, I’m asking two different things at the same time because of the structure of the seconds and the timezone. It seems that as long as they are in sync (I should also add the “@”, but since it doesn’t have a real value, I don’t think it matters) it should be fine. What do you think?

4

I didn’t strictly have any strong reason to believe the @ was a problem, it just seemed like the one thing that was somewhat out of place that Go might not handle well.