Hugo 0.55.0 - Date appears as "January 1, 0001"

#1

Each of my posts uses the following to produce “Published” and (if applicable) “Last modified” info at the top of the page:

<p class="text-muted text-sans-serif ctr">
  Published: {{ .Date.Format "January 2, 2006"  }}<br /><span style="font-size: 85%;">
  {{- if ne .Date .Lastmod }}
    Last modified: {{ .Lastmod.Format "January 2, 2006" }}
  {{- else }}
    &nbsp;
  {{- end }}
  </span>
</p>

Starting with Hugo 0.55.0, that works fine on a post but the same code on my site’s “About me” page produces the following result:

Published: January 1, 0001

[And it ignores the “lastmod” parameter altogether, apparently considering lastmod also to be 0001-01-01.]

I tested this in Netlify by deploying first as 0.55.0 where I got this anomalous result, as I had been getting on my local system with 0.55.0, and then re-deploying to Netlify as 0.54.0 which returned it to its normal condition (https://brycewray.com/about/). So, obviously for now, I will keep production site at 0.54.0 — but I find this a curious bug since it happens even when the .md files for each have identical items in the front matter (i.e., I “cheated” the “date” and “lastmod” parameters for /content/about/_index.md to match a properly working post’s same parameters, just to see if I had a character wrong or something like that; still got the bad result).

Any thoughts/help greatly appreciated.

0 Likes

Friendly reminder, you don't have to wait on a package manager
#2

Sorry to reply to my own, but I found a kludge that stops this just in case anyone else has the problem. If I put another file in the /content/about/ directory, that stops the odd behavior. However, if I delete that other file, or make the other file’s “draft” status “true,” or even put the expiryDate in the other file’s front matter, the problem returns and my real page is back to showing “January 1, 0001” as the date of publication. (I also switched “.Date” to “.PublishDate” and the result was the same. Indeed, even “Lastmod” rendered as “0001-01-01 00:00UTC” when I tested only that.) I briefly rolled back to 0.54.0 yesterday locally and the problem went away; then I came back to 0.55.0 and problem returned, whereupon I found this little kludge this morning.

When I tested with this paragraph (and this is with the other file in the directory):
<p>Date: {{ .Date }}<br />PublishDate: {{ .PublishDate }}<br />Lastmod: {{ .Lastmod }}</p>

… I got:

Date: 2018-09-14 21:00:00 -0500 CDT
PublishDate: 0001-01-01 00:00:00 +0000 UTC
Lastmod: 2019-04-06 06:09:00 -0500 CDT

I haven’t seen other similar reports, so — especially since I am using the same parameters on other posts, and in other directories which have only one .md file, without difficulty — have to imagine it’s a 0.55.0 bug that hasn’t bitten anyone else yet.

0 Likes

#3

I have one post (list page) that this is affecting. It doesn’t appear to relate to the date formatting in the front matter.

I’m going to have to look into this further. My initial checks have come up blank.

Edit: Looks like it has affected a few posts.

1 Like

#4

OK, after an initial look it seems that I am using different references for publishdate in different places.

For example:

  • .PublishDate
  • .Params.publishdate (this is how I have defined it in front matter (all lower case))

Are just a couple I have found. I will need to go through my site and do some search \ replace to make everything sync up I think. It looks like my error.

The docs seem to imply that I should be using:

  • publishDate

see: https://gohugo.io/content-management/front-matter/

I think I have also overlooked (I started the site when I knew virtually nothing about Go Hugo, so looks like some early errors catching up with me).

For instance:

Frontmatter = date
page variable = Date

I’ve obviously overlooked capitalization at some point.

I’ve muddled some other date variables too, and ended up referring to them as .Params.date. Basically my dates in the project need a complete revamp.

0 Likes

#5

I will try publishDate in the front matter next time I have a chance, although — again — wasn’t encountering difficulty until 0.55.0 and it’s happening only in this one instance. While there were some things that Hugo reported as deprecated that I fixed, saw no such warnings about my existing date info. And the “bogus file also in the directory fixes it” thing has me totally baffled. :slight_smile:

0 Likes

#6

@bwintx It may be that I spoke too soon. Whilst I am having to improve my date handling to deal with some “other” date bugs I found I have not been able to resolve that one listing page.

The dates schema are inserted by a partial that works on other pages, and I have checked, and even copied date and lastmod dates from other md files, and still get the 0001-01-01 00:00:00 +0000 date.

Update: I have identified my issue, and created a new post here: Lastmod & Date on List Pages - Is this expected behaviour?

1 Like

#7

OK, one more and I promise I’m done. I tried publishDate as promised earlier. No change in the anomalous behavior. What I further found is that my /about/_index.md file’s front matter date info is being ignored — Hugo is pulling it from the bogus file that I have to put in there! In fact, if I delete or comment out the bogus file’s date info, the Web page once again reverts to the “January 1, 0001” behavior. It pulls all the other content from the proper .md file just fine, just not the date info (date, publishDate, lastmod — whatever). Very, very strange.

1 Like

#8

I’ve checked through my deploy history, and can confirm that this occurred after updating to hugo 0.55 for me.

Reverting to 0.54 fixes the problem.

Specifically, Hugo is using the Lastmod and date values on list pages (_index.html) from the most recent post in that section, not from the front matter of _index.md.

If there is no post in the section (other than _index.md), then the date is 0001-01-01 00:00:00 +0000 UTC.

I think the only thing left for us to do @bwintx is to create public repo showing this and submit a bug report.

1 Like

#9

I definitely am publishing online with 0.54.0 for now. Agree. Will address the rest this evening (U. S. after day job, assuming there’s been no change in the situation in the interim — i.e., @bep et al. haven’t addressed this somehow with at least a “we’re looking at this” message of some sort). Thanks, @Jonathan_Griffin.

Edit: With 0.55.1 now released but not yet available via Homebrew, I’ll wait until I can upgrade to that version and see if that addressed the issue, although the bugs reported didn’t sound anything like this.

0 Likes

#10

Just installed 0.55.1 (thanks to Friendly reminder, you don't have to wait on a package manager). Unfortunately, this particular issue remains, as I’d feared. Will be putting a repo on GitHub for a bug report, as suggested earlier by @Jonathan_Griffin.

Edit — Issue reported:

1 Like

#11

@bep has confirmed this is a bug and is addressing for 0.55.2:

1 Like

#12

@bwintx yes, I will release a patch release with this in a few days. That said, I think a regular page would solve your problem and also be a better fit than a section – e.g. “_index.md” => “index.md” should do it.

1 Like

#13

@bep Thank you for the fix and the advice, sir (not to mention Hugo, itself!).

Re your advice: guess I’d misread the docs because I thought it had to be _index.md rather than index.md. Will re-read, and adjust accordingly.

Edit: Yes, I see now. Have adjusted /layouts/_default/single.html and made the file /about/index.md, and all is fine that way on the local install.

0 Likes