In my frontmatter, I have various time zone offsets (e.g. +02:00, +09:00, -04:00, etc) because some blog posts were written in different regions. However, I would like to always display times converted to UTC. How can I achieve this?
For example: Frontmatter says “10:00+02:00”, built page should say “08:00” (or “08:00 UTC”)
Does the dateFormat template function offer what you need?
Possible, but if so, I have no idea how…the whole date/time stuff seems a bit overly complicated, and I can’t find useful examples either so it’s hard to wrap my head around it.
@red_trela Are you talking about just getting the date to from from ISO => your preferred format, or are you having difficult w ISO => UTC => preferred format. If the latter, the formatting for dates seems tricky with Hugo at first (especially when compared to liquid or other mustache-based templates), but the syntax is easier than what you might expect from the typical %Y formatting (PHP, etc).
.PublishDate.Format “Jan 2, 2006”
Just remember January 2, 2006.
Let’s say you are publishing a piece of content on March 18 and have the following at the top of a content .md file:
publishdate: 2016-03-18
Then in layouts/_default/single.html you could do:
{{.PublishDate}} => 2016-03-18 00:00:00 +0000UTC
{{.PublishDate.Format "Jan 2, 2006"}} => Mar 18, 2016
{{.PublishDate.Format "January 2, 2006"}} => March 18, 2016
{{.PublishDate.Format "2006-01-02"}} => 2016-03-18
{{.PublishDate.Format "2006"}} => 2016
{{.PublishDate.Format "Jan 2006"}} => Mar 2016
{{.PublishDate.Format "January 2006" | upper }} => JANUARY 2006
(Throwing in another filter for good measure with "upper")
{{.PublishDate.Format "January 2"}} => March 18
{{.PublishDate.Format "January 2 at 4:00 PM"}} => March 18 at 0:00 AM
(This will format to the correct time if you are including M/H in the front matter for your content)
Is this what you’re looking for? Or do you have a series of markdown files that you want to convert into UTC within the front matter?
If you want to dig a little deeper, you can see some of the logic behind the formatting in the GoLang docs
@rdwatters Thanks for the extensive reply, but that wasn’t my question, I figured that out a while ago. Not sure why everyone says it’s easier than typical “PHP, etc.” formatting, though - but that’s not the discussion I want to have here.
My question is just about time zone conversion. Say my frontmatter has a time in CEST but I want to output it as UTC. For example:
Frontmatter (10 AM CEST):
publishdate = "2016-04-28T10:00:00+02:00"
Output:
2016-04-28 08:00 UTC
Now I know how to get the format:
{{ .PublishDate.Format "2006-01-02 04:00 UTC" }}
…but will output:
2016-04-28 10:00 UTC, i.e. the unconverted time.
This looks like the way you convert timezone in golang, but, I am not sure if or how this could be applied within Hugo.
This post is a bit old and I don’t really know if you solved your problem but I faced a similar problem (the other way, though) and this is how I solved it.
If you have times in several timezones you can use UTC to convert them to UTC. The same way, you can convert UTC dates in your timezone with the Local method.
E.g: if you have in your metadata this date 2008-10-23T20:30:14+09:00 and you use this code:
{{ dateFormat "15:04 MST" $date.UTC }}
{{ dateFormat "15:04 MST" $date.Local }}
You will get (note that I’m in CEST timezone):
11:30 UTC
13:30 CEST
It will apply DST if necessary (October, 23rd, 2008 was still Summer time +2 in CEST).
Anyway you can read more about the available methods on Time values here: https://golang.org/pkg/time
Thanks mate. With your tip I now use $date.Local in my template and Hugo respects my environment TZ="Europe/Berlin". All my timestamps, no matter which timezone they belong to, are now normalized!
In case anyone stumbles upon here looking for a way to display the time of site build in UTC (like I did), you can use the following pattern:
{{ now.UTC.Format "Monday, January 2, 2006 15:04:05 MST" }}
I’m using Hugo to build a site that’s regenerated every hour with data pulled from around the web. Showing my users the freshness of the data is useful.
(Thanks for previous answers for helping me get to this.)