Add ToTimeInDefaultLocation/E

[heewa]

Go's time parsing uses UTC when the format doesn't have a timezone, and has even weirder behavior when it has a zone name but no numeric offset. A caller to cast.ToTime cannot know if the returned time was explicitly in UTC or was set by default, so they cannot fix it. These new functions allow a user to supply a different timezone to default to, with nil using the local zone.

This addresses gohugoio/hugo#1882 by allowing that code to use cast.ToTimeInDefaultLocation(raw, nil).

A note on the implementation: It's not possible to use time.ParseInLocation because parsing with a format that has a named zone but no numeric offset (such as time.RC1123Z) returns a time with a 0 offset in that name iff that's not the current local timezone (!!). You can verify this by changing like 521 to use time.ParseInLocation(format.format, s, defaultLocation) and commenting out the manual override in the body of the if clause – tests will fail.

I think the root cause is that the time pkg has two parsing functions: time.Parse and time.ParseInLocation, both of which use a private workhorse fn time.parse. That private fn takes two zones: a default and what's considered "local". I'm not sure, but I think in order to get the effect we want, we'd need to call that fn with our default and the current local zone. However, time.Parse uses default of UTC, whereas time.ParseInLocation uses the given zone for both default & local.

[CLAassistant]

All committers have signed the CLA.

[bep]

Thanks for this; I'll have reread and try to understand this. Seems a little bit weird from the std lib ...

[heewa]

:) Here's a quick playground to illustrate: https://play.golang.org/p/UqNajdLppw

I'd love a simpler, smaller, cleaner solution. Let me know if you can think of one. Another approach, though it's arguably no simpler, would be to tag formats that have only a named zone & no offset, then use time.ParseInLocation and only manually convert the tagged formats. That way the manual override happens on a smaller set of formats.

[bep]

I haven't forgotten you. I will try to wrap my head around this tomorrow. Your workaround looks fine, but I still think this looks like a flaw in Go's stdlib (which means we should provide this as a temp workaround and hope for a fix ...), but time and timezones are some of the harder problems of computer science ...

[bep]

I haven't forgotten, but busy ... @spf13 any opinion on this?

[bep]

@heewa I'm really sorry to have left this hanging here for several years (time flies!). I have spent some time trying to understand the rather confusing time.Parse API ... And I think I now kind of understand it.

Let us finish this in #79