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?
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
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.
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.
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.
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.
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.