Hugo timezone format issue

I don’t even know how to troubleshoot this one, but when I run Hugo locally I have {{ .Date.Format "January 2, 2006 3:04 PM MST" }} in a template which renders correctly with June 11, 2022 at 2:06 AM PDT

But when I push to the github repo, the build triggers on Cloudflare, and the output format of the timezone has changed to -0700 which sure, is correct, but not. Heh.

June 11, 2022 at 2:06 AM -0700

If I just use the stock {{ .Date }} it should return 2022-06-11 02:06:56 -0700 but it still spits out the additional -0700 for some reason.

2022-06-11 02:06:56 -0700 -0700

I did confirm others are seeing the same issue as well.

Is there a way to dig through the build logs in detail or anything?

1 Like

You probably have not set any timezone, so it falls back to the severtimezone.
To prevent that please set a timezone in hugo like this:

{{ $loc := time.LoadLocation "Europe/Berlin" }}
{{ dateFormat "January 2, 2006 3:04 PM" (.Date.In $loc) }}

That should do the trick. Please also have a read here: time | Hugo

Alternatively you can set a global timezone in the siteconfiguration, have a read here: Configure Hugo | Hugo

Enforcing a timezone with a TZ value in Cloudflare Pages anyway could be a cool feature request @Walshy :slight_smile:

P.S.: please ensure, that you are running the very same version of hugo locally and on Cloudflare Pages. Otherwise different behaviour is to be expected.

1 Like

Ah I see, sorry I think I missunderstood something.

Just for clearification:

  1. you just want instead of the RFC822Z (with -0X00), the RFC822 (with MST) formation of your date?
  2. the Date itself was already right?

Ha. No worries. The date and timezone are correct, although I haven’t set any timezone anywhere. But it’s not following the format set in Hugo after it’s deployed to Cloudflare.

If I set MST as per hugo/go time requires, it should return PDT, and it’s spitting back -0700, which is right…but not what I asked for.

And if I just use {{ .Date }} with the default formatting, it spits out 2022-06-11 02:06:56 -0700 -0700 with the -0700 printed twice.

So I either really messed something up and have no clue, or I triggered some form of bug. Locally I can’t replicate it at all. And I don’t understand if it is even possible to debug the deployment to Cloudflare on my end.

May you want to share which version of Hugo you are running locally and which at Cloudflare Pages?

In this process of troubleshooting, I updated both to 0.100.2 so they’d match with the latest build available.

Thanks, I will quickly run some tests and report back.


{{ .Date }} on own server hugo 0.100.2 = 2021-04-25 02:50:54 +0200 CEST
{{ .Date }} on cf pages hugo 0.100.2 = 2021-04-27 22:20:00 +0200 +0200

Indeed seems to be a Cloudflare Pages bug. Will report this to the team, thanks!

No rush. There is a higher probability I did something horribly wrong on my end. But I’ve seen others report it elsewhere. And then I triggered it and could replicate it.

I assumed the timezone is just rendered based on the front matter of the post.

title: "220612 Test"
date: 2022-06-12T01:41:27-07:00
draft: false

But I have no way to debug it on my end without some sort of verbose build log output from Cloudflare. I don’t even know if something like that exists.

ha. okay. We’re on the same page then and I’m not CRAZY.

That’s good news.

Actually you do :slight_smile:
Hugo does have inbuild verbose output and verbose logging.
Have a read here: hugo completion | Hugo

-v --verboseㅤㅤㅤ verbose output
ㅤ --verboseLogㅤㅤverbose logging

Please wait patiently, untill a dev replies. Today is sunday, so probably not gonna happen today :slight_smile:

Turns out, even though I’m getting the correct timezone returned, in an incorrect format, that it is indeed the TZ setting in the Environment Variables.

I don’t think I’ve ever actually seen a mention of a timezone variable in any Hugo documentation for Cloudflare Pages setups and installs. And since it was spitting back -0700 where I life, I never thought to add it.

That is not needed. This problem does not have something tom do with Hugo, but actually with goLang since it (if no TZ is available) will fall back to sending the timezone offset twice as it does not know the timezone name - hence the -0700 is getting send twice.

To fix that you have been very close:
use the var TZ like this:

TZ = America/Los_Angeles

This will fix the problem.

The request to the dev team, to at least set every instance to a default TZ (Europe/London, would be the default I guess) so the problem can/could be fixed at Cloudflare Pages, even if it roots from goLang.

I have tested it again and with a correct TZ value set it works perfectly fine. Maybe the TZ variable should even be set by default, so people just have to edit it.

Like mentioned above: setting the timezone hugo wide to any valid value you like, should have fixed the issue aswell.

1 Like

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