time.ParseInLocation fails silently

[NieomylnieJa]

Hey :)

https://play.golang.org/p/LSIObUBjLLn

What I expected was an error since UTC offset doesn't match that of 'Europe/Warsaw' (+01:00), but instead the method returns no error and time which 'loc` is nil. Not to mention I was expecting this method to act like 'time.Parse' + 'time.In' chained. I'm using go 1.16 btw. How comes it acts like that?

[Ian Lance Taylor]

On Wed, May 26, 2021 at 9:09 AM NieomylnieJa <matih...@gmail.com> wrote:
>
> https://play.golang.org/p/LSIObUBjLLn
>
> What I expected was an error since UTC offset doesn't match that of 'Europe/Warsaw' (+01:00), but instead the method returns no error and time which 'loc` is nil. Not to mention I was expecting this method to act like 'time.Parse' + 'time.In' chained. I'm using go 1.16 btw. How comes it acts like that?

Using Z as a timezone always means UTC. ParseInLocation sets the
timezone location if the time string does not give an explicit
timezone. In this case your time string does give an explicit
timezone: Z == UTC.

Ian

[NieomylnieJa]

But the docs state something different:

// ParseInLocation is like Parse but differs in two important ways.
// First, in the absence of time zone information, Parse interprets a time as UTC;
// ParseInLocation interprets the time as in the given location.
// Second, when given a zone offset or abbreviation, Parse tries to match it
// against the Local location; ParseInLocation uses the given location.

The docs explicitly state that: "ParseInLocation interprets the time as in the given location". This behavior in conjunction with the docs were confusing to me and a number of my coworkers, shouldn't they be updated? It's not quiet straightforward that this line "First, in the absence of time zone information (...)" refers to "ParseInLocation" too, the semicolon doesn't help either, as the interpretation may differ: Merriam-Webster reference

[Jan Mercl]

My understanding is that UTC time is the same regardless of
location/time zone where it is interpreted. If that's correct, then
ParseInLocation works as intended.

[Ian Davis]

I think those docs are clear:

(1) in the absence of time zone information Parse assumes UTC but ParseInLocation uses the location's timezone.

(2) when a timezone is given Parse uses the Local (current) location to resolve the name of the timezone, but ParseInLocation uses the location passed. This allows local names for timezones to be resolved correctly. For example CST has several different possible meanings.

However Z is an unambiguous timezone - it always means UTC. So your example will use UTC for the timezone.

Ian

[NieomylnieJa]

Thank you for your responses. While I'm convinced that `ParseInLocation` works as intended and I do get that UTC is an unambiguous zone, the only thing I still have problem with is with the way this is phrased in the docs. I had 5 of my colleagues looking at it and none of us has had clarity as to how to interpret these lines:

// First, in the absence of time zone information, Parse interprets a time as UTC;
// ParseInLocation interprets the time as in the given location.

All I'm saying is that it sounds like `Parse` interprets time as UTC in the absence of TZ information, while `ParseInLocation` will interpret it in the given location period (disregarding the TZ if provided).
As the Merriam-Webster reference to the semicolon usage also leaves space for the interpretation the docs should avoid semantically ambiguous lines like those in my opinion. What do you think?

This would be clearer to me (although I've got no idea what style rules, If any are required for the docs):
// First, in the absence of time zone information:
// - Parse interprets a time as UTC
// - ParseInLocation interprets the time as in the given location

[Axel Wagner]

IMO, if we change it, we should change the ";" into ", while". I think natural language is better than formatted bullet points.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/05d761f3-234e-4c24-9073-b3b0a9b850f9n%40googlegroups.com.