On Fri, 28 May 2021, at 11:32 AM, NieomylnieJa wrote: > 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 > <https://www.merriam-webster.com/words-at-play/a-guide-to-using-semicolons>
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 -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/29e7e4d7-9e20-4a69-851c-0536df27ed0f%40www.fastmail.com.
