Document Dates in Front matter

Can I request some greater clarity on in the documentation site around how dates should be formatted in the front matter to work with Hugo and all of the functions?

I am not clear if there is one exact format to follow, or multiple formats that could be used, and if so what are those formats?

At the moment, the only date configuration that seems to work across the board is:

date: 2017-01-19 12:09:32 -0400

Ideally, I would like to remove the timezone offset, as that changes twice a year with daylight savings
And I would also like to remove the milliseconds, as that is often confusing for editors.

Removing the timezone offset seems to bust {{ .LastMod }} but work most other places

date: 2017-01-19 12:09:32

Removing the milliseconds seems break all my range statements across the site

date: 2017-01-19 12:09

Does this mean that this is the only date permutation available in the front matter?

date: 2017-01-19 12:09:32 -0400

Either way, it would be nice to make the default more clear in the docs. Happy to help.

One more thought — Is this a YAML limitation more than a HUGO limitation? Not sure.

Why would you want to remove the timezone marker? If it changes then the marker would change too? It is a standard. Any parser would know that 2017-01-19 12:09:32 -0400 means “that time, but 4 hours AFTER UTC” It’s your place at 12:09. But compared to international timezones it is also 4.09pm in London. So YOUR post comes BEFORE the Londonians post at 4.10pm.

This standard (meaning plenty of people discussed it and thought about it) is not for you and for readability, it’s for that thing we humans did with timezones.

And yes, removing parts of a standard breaks it.

It’s one of these “See it, accept it, forget about it” things. It’s nothing Hugo developers developed to feed their weird fetish of punishing us users :slight_smile:

PS: my dates look like this: 2019-06-10T20:04:48+07:00 and if I do it by hand I always use zeroes to make the Gods of parsers happy: 2019-06-10T20:00:00+07:00

We have a few thousand pages on our site, half have -0400, the other half have -0500.
I guess this means that we need to do a big find and replace a few times a year to update the timezone offset? Or am I missing something?

You miss, that the timezone offset has no relevance for YOUR time. If it’s 5pm it’s 5pm in summer time and in winter time. Both date stamps will show 5pm, one will show -0500, the other -0400. But in the context of your time it’s 5pm.

For ME, an outsider from timezone UTC+7 trying to parse your documents to put them into my big portal of posts regarding your topics it shows the time relative to Universal Time Zone (UTC). Which means your 5pm is my (5pm + 4 or 5 hours + 7 hours). Enabling me to put your posts into a timeline that fits with time.

Check your times. If you post at 5pm at your place it will always show the “right” time of your timezone (5pm) on the left and the timezone part will show the “current” difference to UTC. That is “just” info.

Leave it as it is. It’s good.

As of Hugo v0.55.6 (since this is the version I’m currently testing on), the default date archetype is:

date: {{ .Date }}

Which, when you generate a new page, will look like this:

date: 2019-06-11T10:07:49-05:00

I don’t recommend it, but if you wanted to create new pages without a timezone offset, you could edit your date archetype as follows:

date: {{ now.Format "2006-01-02T15:04:05" }}

Wouldn’t that lead to the issues @jeremyzilar described? Like leaving {{ .LastMod }} and some range commands broken?

Maybe THOSE are bugs?

Possibly, hence why I said “I don’t recommend it”.
I’m in the camp of: educate folks, them trust them to use that knowledge appropriately.

Also, .Lastmod will not break, as long as your format the 2 dates being compared, as the same format.

1 Like

By the way, the date parser knows that your summertime is -4 hours and winter time is -5 hours with exact start and end dates of those time changes. Your displayed publication times are not changed if you run hugo 6 months apart, they will stay the same.