MST showing as +0900 instead of the "MST" value

Format is: 2006-01-02 15:04 MST

But instead of showing “JST” or “KST”, it is showing only +0900 for pages set in ja or ko.

To make it easier to explain, I uploaded a test site:

With timezone offset in frontmatter date:

WIthout timezone offset in frontmatter date:

The source code is located at: GitHub - techmagus/hugo-test-site: YourOnly.One's Hugo Test Site

You will notice in the test posts:

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


This might be a stupid question, but is KST/JST in UTC+9? Or to be more specific, is the formatting wrong or are the timezones wrong?

That’s correct, KST and JST are UTC+0900.

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. :slight_smile:

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
1 Like

Here are screenshots. (online | source code)

ja (UTC+0900) language

no timezone offset

with timezone offset

ko (UTC+0900) language

no timezone offset

with timezone offset

en-ph (UTC+0800) language

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

no timezone offset



with timezone offset



Both .Date.Format and time.Format should display the timezone abbreviation (examples: PST, EST, CEST, PDT, KST, JST). However, the output of:

  • time.Format is incorrect with or without a timezone offset in the date frontmatter param
  • .Date.Format is incorrect only when there is a timezone offset in the date frontmatter param

To make things more odd, the en-PH language is:

  • all correct when viewed locally in my system
  • producing the same incorrect outputs like ko and ja when generated in gh-pages


  • 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

I don’t know what’s going on here.

Test site source if you want to check if you can duplicate the scenarios above; or check the settings.


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

Currently on Hugo 0.100.1

1 Like

I came across this thread today in Cloudflare:

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.

1 Like

Oh, it was you. :slight_smile:

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.


1 Like

Netlify does spit out the same result, until you add timezone to netlify.toml

    HUGO_VERSION = "0.100.2"
    HUGO_ENV = "production"

Then it works.

But the datestamp/timezone displayed was correct, just formatted incorrectly until I added timezone.

Adding the same environment variable to cloudflare did the trick.

1 Like

I take it, it works only for one timezone?

So, if your site is multilingual … ?

Okay, just tested this workaround:

TZ = /usr/share/zoneinfo/region/city

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:

It doesn’t work if the hugo-config and/or frontmatter timezone is different from the TZ environment variable:

Tested in Cloudflare Pages:

I haven’t tested in Github Pages but more likely than not, the result will be the same.

Note: The checkmark or x-mark shown in the above sample links are automatically generated on build if it matches the expected field. The source for the test site is at: GitHub - techmagus/hugo-test-site: YourOnly.One's Hugo Test Site

Just to keep track of things, linking CF’s reply:

While the reply is about the timezone value being sent twice, might be useful info re: GoLang.

I also opened a followed up post here (since the workaround “TZ environment variable” won’t work for multilingual sites across different timezones):

And yes, the conclusion is … definitely a GoLang issue.

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.

I think I’m starting to understand this more.

GoLang’s Parse (see: time package - time - Go Packages) provides the Zone Abbreviation based on the local (the system) timezone.

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

Also found this answer: Why doesn't Go's time.Parse() parse the timezone identifier? - Stack Overflow

(I’m sidetracked far too long today … so … shelving for some other time.)