Just to be clear, my timezone is Europe/London, aka. BST, aka. +0100

I can reproduce on Linux or Mac, with:

$ TZ=Europe/London go run repro.go
UTC: 0x528aa0 UTC
Local: 0x52ae80 Europe/London
tl1: Format: "+0000" Location: 0x52ae80 Europe/London
tl2: Format: "+0000" Location: 0xc42009c060

Here's the relevant code:

        if zoneOffset != -1 {  
                t := Date(year, Month(month), day, hour, min, sec, nsec, UTC)  
                t.addSec(-int64(zoneOffset))  
  
                // Look for local zone with the given offset.                                                                                                             
                // If that zone was in effect at the given time, use it.                                                                                                  
                name, offset, _, _, _ := local.lookup(t.unixSec())  
                if offset == zoneOffset && (zoneName == "" || name == zoneName) {  
                        t.setLoc(local)  
                        return t, nil  
                }  
  
                // Otherwise create fake zone to record offset.                                                                                                           
                t.setLoc(FixedZone(zoneName, zoneOffset))  
                return t, nil  
        }  

It's trying to map the timezone to your local timezone if your local timezone was applicable for that time. In this case, it's looking to see whether Unix time -62167219200 (year 0) was a valid British Summer Time. It then fails to find a valid timezone at year 0 and returns some zero values (including offset == 0), and then helpfully matches the zone you specified! So it matches your local timezone.

Looking at a fix.

More particularly, Unix time -62167219200 in Europe/London was GMT, but somewhere before Unix time 0 (sometime in the following 1970 years), daylight savings time was invented and it was now British Summer Time, with offset 3600 seconds forward, which didn't match your +0000, so your local time zone didn't apply then.

I'm tempted to ignore this rule before December 1, 1847-ish, when time zones first started being used. Or I'll see what the earliest recorded zone in the Olson database is. Oh, that's just from 1970. Easy enough.

CL https://golang.org/cl/44032 mentions this issue.

Moving discussion from the CL back to the issue.

I said:

It's not entirely obvious to me that the behavior reported in the issue is wrong. It does seem to match the documentation of time.Parse.

@bradfitz replied:

The docs say "if the offset corresponds to a time zone used by the current location (Local)", so the question is what the definition of "corresponds" is. I'd argue that in year 0, there weren't timezones yet, so +0000 mapping to Local because the user today is in London is kinda weird.

To which I say:

Yes, it is weird, but an arbitrary cutoff at a point in historical time is also weird, whether the cutoff is 1970 (start of Unix time) or 1847 (invention of timezones).

I think the behavior of time.Parse in trying to set the location to time.Local when possible is kind of weird, but maybe I just don't get it.

But the current behavior does seem to match the docs, so if we change this, we should change the docs. And if we approach it from that perspective, what do we want the docs to say?

Yeah, the more I think about it, the more I dislike an arbitrary cutoff and more docs too.

The current behavior is documented and there's a workaround for people who really care: time.ParseInLocation.

I'm happy closing this.