If frontmatter date param have a timezone offset: both .Date.Format and time.Format does not produce the correct language abbreviation for ja (JST) and ko (KST) but works fine with en-PH (PST).
If frontmatter date param does not have a timezone offset: time.Format does not produce the correct language abbreviation for ja (JST); ko (KST); and en-PH (PST); but .Date.Format works fine.
UPDATE: hah, I just noticed, letting gh-pages build hugo messes up en-PH (PST) too. But when I test it offline, en-PH (PST) works perfectly.
The formatting is wrong since it was set to 2006-01-02 15:04 MST and as per GoLang and Hugo docs, MST should show the timezone abbreviation – in this case JST and KST if the <html lang=""> attribute is detected as ja and ko respectively. Or, PST if it is en-PH (UTC+0800).
This gets weirder because building the site locally, it works perfectly for PST/en-PH (UTC+0800). But as shown in the online example site, when the site was built by gh-pages, PST/en-PH (UTC+0800) is showing the same incorrect formatting as ja/JST (UTC+0900) and ko/KST (UTC+0900).
I think what happens here is something along the lines of the used library defining how in your language the timezone is formatted (characters vs digits). We had that issue slightly related with currencies where US dollars had the dollar sign, and British Pound had UKP as “money marker”.
I am not sure how to apprehend the issue, but maybe you could post your translation configuration and from there we go.
Also compare your local Go, Hugo, System versions to those on your deployment. Maybe you can force GH-pages to use your local settings.
I’m not sure what you mean by ‘translation configuration’. I mean the time format is a Hugo / Go built-in feature there is nothing to configure.
In any case, the source code for the test site is in the original post, or here, it has the barest setup.
GH-pages isn’t the problem per se. I only mentioned it because the test site is hosted there and I noticed it produced a slightly different result. I build my sites locally then upload it to Keybase.
In any case:
Hugo on my system and on gh-pages are both v0.96.0
OS: my system Ubuntu 20.04; gh-pages Ubuntu 20.04
Go: my system go version go1.18 linux/amd64; gh-pages – I can’t find this info
This is the weird part. The results from local testing and gh-pages are different. (Note: gh-pages is not the issue, I only mentioned it because the test site I uploaded is hosted there and I noticed this difference from local.)
I just came across this as well (at least it looks like the same issue) using github deploy to cloudflare Pages. I never noticed it before but this is one of the few times I’ve tried to put a timezone like PST/PDT into a template.
Locally I have Hugo spitting out PDT with correct date/time, once to ships to cloudflare the build returns -0700
If CF fixes it, then the issue I described in the OP (hosted on Github Pages) is probably similar … GH related. (Or, maybe not even related … no idea what’s going on in this mysterious inconsistency.)
In any case, added the CF thread for tracking/reference.
Just to reiterate, the OP is Github Pages hosted. But the ‘MST’ rendering issue appears to be similar.
I tripped it twice today, so that was me posting on Cloudflare. I wanted to get verbose logs out of the build to see if it was me or not. And if there is some timezone config I needed that I didn’t do correctly and the formatting was just trippin on not having a timezone set. No joy as of yet. Still tinkering.
I’m tracking the CF thread. If it turns out to be a server config, then it’s probably the same for Github Pages (and I’ll open a similar thread in GH if CF fixes it on their end).
I’m also starting to suspect it’s system related. Probably the system doesn’t have complete timezone data or something.
My timestamp comes back correct to the posts frontmatter, which was generated locally by me. So that all matches. I’m getting back incorrect formatting on the output that is rendered.
I was also able to replicate it on Netlify just now. So that leads me to think it’s some form of timezone setting/mismatch with the servers.
Gonna sleep on it, cause I feel a little crazy after trying to track it down in my spare time for a few days. I will laugh when I actually just skipped some step that I should have done for the last year.
I can’t say I’ve ever noticed an issue before, but this didn’t occur until I put the MST in the time.Format.
Ooh, if it’s happening in Netlify too more likely than not server related. Probably desktop setups are more flexible or have the necessary files to convert timezones to MST-type display.
It only works if you have one time zone. If your site is multilingual, which means your timezone is different for each language, it will only work for the timezone that matches the environment variable that was manually set.
It works if TZ environment variable matches the hugo-config and/or frontmatter timezone:
Pages also requires TZ = America/Los_Angeles as the environment variable. I seriously couldnt find any documentation of this anywhere. And I found reports of the same issue dating back to 2018.
While ParseInLocation (time package - time - Go Packages) provides the Zone Abbreviation based on the given (what was provided) timezone.
So if I understood this correctly, with Parse, if the provided timezone doesn’t match the local/system timezone, the Zone Abbreviation is not given instead it gives +0800 or -1000.
But with ParseInLocation, it uses the given timezone, looks at the IANA database, pulls the Zone Abbreviation and uses that.
I haven’t tested this in Hugo (or Go itself), I’m currently not setup to do so. Just leaving it here as a note (and I accidentally came across this while looking for something else).
