Hugo 0.99.1 bug with date and multiline summary (please test)

In my Windows 10 Hugo extended 0.99.1 stop updating files when:

  • editing “summary” fields written as
summary: >
 line with 1 spacing
 line with 1 spacing
  • update ISO date
date: 2022-05-26T11:39:40+01:00

in YAML frontmatter. After couple of editing and saving, pages desappear in listing and give 404 error.

Restarting Hugo has no effect, bug persist and this is very strange.

If you wanna test, this is a demo repo.
To see this behaviour, click on “Orari corsi 2021-2022” and you see 3 pages listed. Edit “summary” and “date” in of those page frontmatter (I.E. “Corsi in Zona Loreto” and after a couple of modify and save the page desappear from list.
Sometimes pages give also 404 error.

Now edit date in list page, close Hugo, restart Hugo… and same list page give 404 error. This is incomprehensible for me.


In your /content/category/orari-corsi-2021-2022/ file, the date frontmatter is set to the future.

date: 2022-05-26T11:49:20+01:00

(aside: It’s currently 18:35+08:00 my local time, as of this post, it’s only 11:35+01:00 if I got my conversion correctly.)

For hugo server to build future dated content, you need the --buildFuture flag, like so: hugo server --buildFuture.

You can also use that flag in hugo to build future dated content, however, that means all content with future dates will be published as well.


1 Like

Wow, drive me crazy two days. Flag --buildFuture it’s perfect for my problem. Very thanks for your time and explain.

So is my fault with date: generatd with string “+01:00” for time zone after current time (so it’s translated 1 hour after; and this require flag --buildFuture to view those pages). Best to adjust my routine for date.

Thank you for point me right :pray:

1 Like

Glad to be of assistance. :slight_smile:

You can check other flags here:

Some of them may be useful in your workflow, like --buildDrafts. (see: Draft, Future, and Expired Content)

1 Like

Now time is 15:33 here. Hey Python (3.6.5), who time is it in ISO format suitable for Hugo?

import datetime
import pytz'Europe/Berlin')).isoformat('T', 'seconds')


So this is the problem. Wrong format from Python, or Hugo assumes this time two hours into the future.

But reading this ISO 8601 Date time Corticon.js serverless mobile

2020-02-08 09+07:00 — As format ±HH:mm This date time has an offset of seven hours from UTC. In other words it’s at 9 a.m. in time zone +7.

Hugo does a wrong assumption about time zone OR my Python installation lack some component and give wrong result.

Not sure about the Python error but Hugo’s datetime feature is based on GoLang and understands timezone correctly.

Also, if I understand your workflow, you have a Python script that generates the date value for the Hugo frontmatter, right?

If so, the error is on the Python script since the whatever value is entered in to the date frontmatter is what Hugo will use.

See the following for reference:

Going back to your example, 2022-05-26T15:33:06+02:00 is correct, it is in ISO format and it is what I use in my .md files.

If anything, have you tried changing your /archetypes/ (or whichever archetype file you’re using) and use {{ .Date }}?

For example, in TOML I have this:

date = "{{ .Date }}"

When I use this command hugo new, it will automatically put the current date and time in your frontmatter date.


Regardless which method you choose to put dates in the frontmatter date, it is what Hugo will use.


  • Current time (my local as of this post): May 27, 2022 05:24:44

  • My timezone is: UTC+8

    date = "2022-05-27T07:24:44+08:00"

    The above is two hours in the future. Hugo will display the frontend date to May 27, 2022 07:24 (if I use the format).

    date = "2022-05-27T06:24:44+09:00"

    The above is current time even though the timezone is different. Hugo will display the frontend date to May 27, 2022 06:24 JST/KST (again if I use that display format).

Another thing, check if the system where Hugo is installed has the correct time and timezone. GoLang (or Hugo?), uses the system’s time when computing timezone differences.

I hope I understood your question correctly?

@techmagus first of all thank you very much for your time and efforts.

My script doesn’t support correct timezone, so I have appended “+01:00” and this require the --buildFuture flag.

So i thought: “+01:00” means “1 hour BEFORE +02:00” time, not after.
16:19+02:00 == 15:19+01:00

Hugo thinks otherwise:
16:19+02:00 == 17:19+01:00

And ok, if Hugo is happy there, then I’m happy too (thanks for flag :slight_smile: )

Hmm… I’d like to clarify something but first here is my setup (as reference).

In my English pages:
date = "2022-01-01T01:00:00+08:00" frontend as 2022-01-01 01:00 PST (Philippine Standard Time)

In my Japanese pages:
date = "2022-01-01T02:00:00+09:00" frontend as 2022-01-01 02:00 JST

In my Korean pages:
date = "2022-01-01T02:00:00+09:00" frontend as 2022-01-01 02:00 KST

I manually adjust the time as well as the timezone because the date frontmatter doesn’t auto-convert the time. It does recognize timezones but it won’t convert it automatically. (Only .UTC, if present in the code, is auto-converted.)

In your case, date = 16:19+02:00 is rendered as 17:19+01:00?

If it is rendered as 17:19+01:00 that’s weird. It should be rendered as 16:19+02:00 if that is what’s in the date frontmatter. So, if you want it to show time in +01:00, the date frontmatter should have 15:19+01:00.


@techmagus I have only this computer in Italy (so UTC +1 and +1 daylight saving = +2).

Now, without TZ, my watch says 18:35. This is current time in Italy.

Hugo new… command says


My script says


without TZ. I attach string “+01:00” only to conform Hugo requirements (because a pytz error hard to resolve, for me).
This is not the “true” current time with TZ, but a fake made by me :slight_smile:

To answer your question, watch time “18:35” is rendered as “18:35+02:00” by Hugo, and it’s OK for me.

What I thought was consider “18:35+01:00”, for me, “real” 17:35.
Hugo instead consider “18:35+01:00” AFTER “18:35+02:00”, and this require future flag.
It’s all ok for me.

P.S.: see now another problem with datetimes :sweat_smile:: getting this

<meta property="article:modified_time" content="{{ .Page.Lastmod }}" />

rendered as

<meta property="article:published_time" content="2022-05-27 16:22:45 &#43;0200 CEST" />

The timezone offset is optional. You can do it like this: date = 2022-05-27T18:35:34 or 2022-05-27T18:35. Hugo will simply assume “local” time (as set in the OS Hugo was executed) or based on the timezone config found in the config file (if you added one, for example mine is timeZone = "Etc/UTC" so content without a timezone offset in date will assume UTC).

Yep, that is correct.

Hugo should display it as 18:35+01:00.

And this is the weird part, it should not do that. Hugo should be rendering it as 18:35+01:00 since that is what’s in the date frontmatter. If it shows 17:35 or 19:35 there is something else interfering.

I pulled your test repo again and set my system’s timezone to Italy.

Current time for this test is 2022-05-28 03:20 +02:00.

hugo new generated

date: 2022-05-28T03:20:00+02:00

Since the theme doesn’t display the time in the frontend, I checked the source instead

<meta property="article:published_time" content="2022-05-28T03:20:00+02:00" />
<meta property="article:modified_time" content="2022-05-28T03:20:00+02:00" />

I then changed the post date to: date: 2022-05-28T03:20:00+01:00

I then reloaded Hugo for good measure, the time in source is:

<meta property="article:published_time" content="2022-05-28T03:20:00+01:00" />
<meta property="article:modified_time" content="2022-05-28T03:20:00+01:00" />

I changed the timezone offset to +3: date: 2022-05-28T03:20:00+03:00

The content’s time is:

<meta property="article:published_time" content="2022-05-28T03:20:00+03:00" />
<meta property="article:modified_time" content="2022-05-28T03:20:00+03:00" />

I can not duplicate what you’ve been experiencing. This is why I think there is something else causing it.

For the time to change, it has to be manually changed in the date frontmatter. For example,

date: 2022-05-28T03:20:00+02:00

If you want to display non-DST, change the date time and timezone:

date: 2022-05-28T02:20:00+01:00

In any case, since the theme is not displaying the content’s date, you can look into this some other time in the future (pun intended). Search engines care more about the date than the time of content. :slight_smile:

As for this:

I’m not seeing it in the test repo you provided. The source is fine:

<meta property="article:published_time" content="2022-05-28T03:20:00+02:00" />

That code comes from {{ template "_internal/opengraph.html" . }} and in your test repo, you’re using the default that comes with Hugo (see: hugo/opengraph.html at master · gohugoio/hugo · GitHub ) so it should not be displaying a different time format.

This is the part related to that:

{{- if .IsPage }}
{{- $iso8601 := "2006-01-02T15:04:05-07:00" -}}
<meta property="article:section" content="{{ .Section }}" />
{{ with .PublishDate }}<meta property="article:published_time" {{ .Format $iso8601 | printf "content=%q" | safeHTMLAttr }} />{{ end }}
{{ with .Lastmod }}<meta property="article:modified_time" {{ .Format $iso8601 | printf "content=%q" | safeHTMLAttr }} />{{ end }}
{{- end -}}

The default _internal/opengraph.html is set to this format {{- $iso8601 := "2006-01-02T15:04:05-07:00" -}}.

I also checked your theme, since some themes include their own opengraph tags, but your theme doesn’t have any custom OG.

I’m thinking the test repo is no longer the same as your main project repo. I tried to search for <meta property="article:modified_time" content="{{ .Page.Lastmod }}" /> but did not find it.

Take a break, enjoy the weekend!


@techmagus Thank you very much for efforts, advices and code :heart_eyes:

I have updated my head.html with code for lastmod; and update the repo also. Hugo internal template for open graph doesn’t work well with “leaf bundle”, but have found this working solution:

{{ if .Page.Params.featured_image }}
<meta property="og:image" content="{{ .Page.Permalink }}{{ .Page.Params.featured_image  }}"/>
<meta property="og:image:secure_url" content="{{ .Page.Permalink }}{{ .Page.Params.featured_image  }}"/>
{{ end }}
{{ if .Page.Params.images }}
  {{ $permalink := .Page.Permalink }}
  {{ range .Page.Params.images }}
  {{ $img := . }}
  <meta property="og:image" content="{{- $permalink -}}{{- $img -}}"/>
  {{ end }}
{{ end }}

then I will also put the code for “series”. Thanks to pointing me.

Regarding dates and time zones, I removed the timezone from my Python script and now date: in frontmatter is simple:


(N.B. not in the repo). Using this simple date without explicit TZ, on my computer, if I remove --buildFuture flag, I lose pages I am editing. Restarting Hugo with the flag, pages reappear.

No idea about why, but I’m happy anyway with flag :slight_smile:

Thank you for all suggestions :pray:

Yeah, it’s weird. But you can look into it some other time, what’s important is the site and the content. :slight_smile:

As for the lastmod (and related), at least in the source, there are different ways to do it.

{{ .Format $iso8601 | printf "content=%q" | safeHTMLAttr }}
[what I usually use]: {{ .UTC.Format $iso8601 | safeHTML }}

These are the relevant docs:

Then don’t forget to pipe it through these (so the + and - stay as is):

One more thing, the time format for HTML meta date/time should be in iso8601, the same for Atom feeds. For RSS feeds it should be $rfc822 := "Mon, 02 Jan 2006 15:04:05 -0700". (You can check my feed repo for more: Yelosan Publishing / hugo-feeds · GitLab )

It doesn’t matter which timezone but personally, I added .UTC (but in the frontend, I don’t use it). (see: .Format | Hugo ).

So for example, in my blogs, I have this:

{{- $datetimeformat := i18n "datetimeformat" -}}
{{ if not .Date.IsZero }}<time datetime="{{ .Date.UTC.Format "2006-01-02T15:04:05Z07:00" }}" class="dt-published">{{ time.Format $datetimeformat .Date }}</time>{{ end }}

The date in source is in UTC but the user readable format is one that I prefer (per language).

I hope it helps :slight_smile:

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.