Add proper timezone support

[heewa]

When some pages have dates without timezones, and some with timezones, the page ordering looks incorrect. The pages with only dates, or dates+times get interpreted as UTC times. This can cause a page with date = "2016-02-18T20:00:00-05:00" to appear as a later post than a page with date = "2016-02-19".

If you understand what's happening under the hood, you can see why, but for a non-developer, or even one that doesn't understand this specific implementation quirk, that posts to inexplicably appear in an incorrect order. Intuitively, 2016-02-19 would refer to a date, not specifically midnight on that date in England.

The library that hugo uses to parse dates (spf13/cast) will parse these date formats that don't include a timezone:

1. 2006-01-02T15:04:05
2. Mon Jan _2 15:04:05 2006
3. 2006-01-02 (This one is what a user would get if they manually cut off the time portion of the date. That's how I stumbled on this issue.)
4. 02 Jan 2006

There are probably a few ways to make the behavior more friendly. I don't have an opinion on these, I'm just throwing out suggestions:

1. When parsing pages, detect date values that did not include a timezone and explicitly put them into the local timezone of the user, maybe with a user-configurable site-wide default timezone.
2. When parsing pages, if there are only two timezones across all pages: UTC + a non-UTC timezone, convert all the UTC dates to that other timezone. Possibly include a config setting to disable this behavior.
3. Throw an error if a timezone is not explicitly stated in a date value.
4. When a page is created with the hugo tool, insert a date without a timezone, so that it will also end up in UTC, like a date entered manually by the user without a timezone. (This would be a half-measure, since any pages created with an older version of hugo would have timezones, as well as any dates manually entered with timezones by the user. Although, for going forward, it would mitigate the quirks that might results from the other solutions.)

[bep]

When parsing pages, detect date values that did not include a timezone and explicitly put them into the local timezone of the user, maybe with a user-configurable site-wide default timezone.

I think this is the best solution to this.

[moorereason]

I'm not sure where this needs to happen (spf13/cast?), but we can use time.ParseInLocation. It respects timezone info if it's in the string, but you can pass in a default. We can use time.Local as the default.

http://play.golang.org/p/nIHv0ilLwS

[bep]

@moorereason we need to have a specified timezone in config (and maybe also as overriden in the page front matter). Once we have this we can say:

1. If timzeone set in the datetime string: fine, use that
2. If timezone set in config (or in page frontmatter), use that
3. Else use UTC (or maybe the timezone used in Norway :-))

We should probably extend cast with another method to solve this, but the current method is a little bit of a convenience method.

[moorereason]

That's what I was thinking, too, but I'm more concerned with how we customize the unmarshaler. BurntSushi/toml can do that, but I don't know about YAML, and JSON.

[heewa]

I had started a change for this in spf13/cast, but I haven't had time to wrap it up & submit a PR. I'll try to get that done Sunday or Monday. There are a few issues with using time.ParseInLocation. I'll bring those up in that PR, plus tests to validate correct behavior.

On the hugo side, @bep, 1 & 2 in your sequence sound reasonable. What do you think of using local timezone in step 3, though? I wonder what portion of Hugo users explicitly want times for their blog posts to be UTC, and of that small group of people, how many of them aren't already listing date values with timezones.

Another benefit of defaulting to local (when no explicit timezone), is that the hugo tool generates pages with local times. So if a user overrides just one of those pages to a a time without a zone, then hugo defaulting to local timezone would keep that page's time consistent with all the other ones.

[bep]

So if a user overrides just one of those pages to a a time without a zone, then hugo defaulting to local timezone would keep that page's time consistent with all the other ones.

Yes, that makes sense.

[bep]

This issue has been automatically marked as stale because it has not been commented on for at least four months.

The resources of the Hugo team are limited, and so we are asking for your help.

If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open.

If this is a feature request, and you feel that it is still valuable, please open a proposal at https://discuss.gohugo.io/.

This issue will automatically be closed in four months if no further activity occurs. Thank you for all your contributions.

[bep]

Note/Update: This issue is marked as stale, and I may have said something earlier about "opening a thread on the discussion forum". Please don't.

If this is a bug and you can still reproduce this error on the latest release or the master branch, please reply with all of the information you have about it in order to keep the issue open.

If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.

[bep]

So, we have spf13/cast#80 which I have tested and that makes sense to me. But when I started to implement this in Hugo I figured out I have no idea how.

• For dates as strings it works fine
• But for dates that are detected as time.Time I'm clueless
• All decoders support some variation of TextUnmarshaler interfaces etc., but I have no idea how to do that with a dynamic map schema. Even if we had fixed structs for all, there is a problem with where to store the location.

If anyone smarter than me could come up with something that works, I would be happy camper.

[jmooring]

This was addressed with efa5760 by adding a timeZone option to site configuration and an optional TIMEZONE argument to the time.AsTime template function.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.