Front Matter datetime duplicated timezone value

support
1

In Octopress I used the following datetime format for my posts:

2015-03-25 22:52:11 +0300

With Hugo this gets parsed into the following value (rendered on the page):

2015-03-25 22:52:11 +0300 +0300

So the timezone is duplicated for some reason.

Another example:

2018-09-09 20:09:15 -0700

becomes:

2018-09-09 20:09:15 -0700 -0700

But! This:

2018-09-22 21:52:45 +0200

becomes:

2018-09-22 21:52:45 +0200 CEST

which is correct.

Is it a bug?

Hugo v0.54.0/extended darwin/amd64

2

See if adding the time zone field in the Date Format in your templates helps. See:

3

But since it doesn’t behave the same way for all the dates even though all of them are in the same format, I suspect it is a bug, so it would be better to fix it globally (in Hugo itself) rather then tinkering with local templates.

1 Like
4

Reported at GitHub.

5

Added a minimal website example to reproduce the issue. Also wrote a bit more detailed comment in the issue.

6

What You Are Doing Now

{{ .PublishDate }}

You are attempting to render the date without any formatting.

{{ printf "%#v" .PublishDate }}

time.Time{wall:0x0, ext:63729022991, loc:(*time.Location)(0xc00059fe60)}

What You Must Do

{{ .PublishDate.Format "2006-01-02 15:04:05 -0700" }}

This will produce a string.

printf "%#v" (.PublishDate.Format "2006-01-02 15:04:05 -0700")

“2020-06-29 13:23:11 +0300”

Please close the GitHub issue that you created.

1 Like
7

That doesn’t feel right, because in case when the date timezone matches the system timezone the output is 2020-06-29 13:33:23 +0200 CEST, which is correct, so it seems to understand the date even with no formatting provided, and it even adds a nice CEST timezone abbreviation (which your example format does not).

8

I don’t know what to tell you.

If you want to understand non-formatted representations of the time.Time data structure (wall, monotonic, and location), read the go docs.

If you want to build a website, format your dates. :grinning:

9

Here’s what I think is happening.

  1. When a format string is not provided, we fall back to 2006-01-02 15:04:05 -0700 MST. Note that both an offset and abbreviation are provided.
  2. When the offset is the same as your current time, the local abbreviation for the offset is displayed. Why? I don’t know; I’m not sure it is the right thing to do. Keep reading…
  3. When the offset is different than your current time, we have no idea what abbreviation to display, so we display the offset again, which is why it looks like it is printed twice.

There is not a 1:1 relationship between offsets and abbreviations. For example, my current offset of -04:00 could be any of the following: AMT, AST, AT, BOT, CDT, CIDST, CLT, EDT, FKT, GYT, PYT, Q, or VET.

For example: if you authored a page with a -04:00 offset, which timezone abbreviation would you want displayed? Cayman Islands Daylight Saving Time (CIDST)? Falkland Island Time (FKT)? Maybe Guyana Time (GYT)? None of those make sense to me. I’m in Eastern Daylight Time (EDT). They’re all -04.00.

The abbreviation is tied to the TZ environment variable on the machine where Hugo is running. If I change my TZ environment, then run hugo again, I will get different results.

Avoid the confusion. Format your dates, and rely on offsets rather than abbreviations. :slight_smile:

This stuff make my head hurt.

1 Like
10

Thank you for such a detailed explanation, it all makes sense to me now. Yes, I will rely on explicit date format from now on.

Just one thing though:

When the offset is different than your current time, we have no idea what abbreviation to display, so we display the offset again, which is why it looks like it is printed twice

Perhaps, it would be better then just not to print the offset second time. I mean, that’s was the only reason why I suspected a bug here - it just doesn’t look right.

11

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.