GMT = UTC+0, Greenwich Mean Time
BST = UTC+1, British Summer Time, daylight saving

Times after 2038 seem to stop adjusting to or from daylight saving zones, because the time exceeds the available timezone transitions.

Instead, the latest available zone transition is returned. It may or may not be in daylight saving. See Location.lookup.

Zone transitions are derived either from the system timezone db (eg /etc/timezone) or from a local copy (eg, $GOROOT/lib/time/zoneinfo.zip). This can be selected by the ZONEINFO env var.

Zone transitions are parsed in LoadLocationFromTZData

	// If version == 2 or 3, the entire file repeats, this time using
	// 8-byte ints for txtimes and leap seconds.
	// We won't need those until 2106.

That code comment might not be correct. The year 2106 is the limit of unsigned 32 bit integer seconds since the epoch, but the timezone information format states These 32-bit values are limited to representing times no later than 19 January, 2038 03:14:07 UTC. (max signed 32 bit int since unix epoch). Looks like zone transitions beyond 2038 won't be parsed, even if available in source timezone data.

Also, extended data is excluded from Go's zoneinfo.zip, to reduce file size. In lib/time/update.bash:

# Turn off 64-bit output in time zone files.
# We don't need those until 2037.
perl -p -i -e 's/pass <= 2/pass <= 1/' zic.c

IANA's documentation (https://data.iana.org/time-zones/theory.html) mentions the issue, with a presumption that 64-bit values are expected:

The tz code attempts to support all the time_t implementations allowed by POSIX. The time_t type represents a nonnegative count of seconds since 1970-01-01 00:00:00 UTC, ignoring leap seconds. In practice, time_t is usually a signed 64- or 32-bit integer; 32-bit signed time_t values stop working after 2038-01-19 03:14:07 UTC, so new implementations these days typically use a signed 64-bit integer.

Is it the feeling here that Go should be using 64-bit values for TZ-related time?

Thank you for the report @jimcheetham and welcome to the Go project! Thank you too @mdcnz for the discussion and debugging.

So we didn't get to this during Go1.12 but I'll punt it for investigation for Go1.13 and @mdcnz if you'd like to take a deeper stab at this during Go1.13, all yours :) I'll also page some other folks too @robpike @ALTree @ianlancetaylor

Gregorian 2038 is the maximum year reachable with the 32-bit signed version from epoch. The tz database used by Go and others introduces issues beyond 2038 and falls back on defaults during that year for daylight saving time between others. This is a known effect as icann mentions. Specifically for Daylight Saving Time (anywhere), its future is not definite beyond 2038. Current behavior seems appropriate.

I think that the Go library is correctly reporting what the TZ database supports. The Go library does now use the extended data, for #30099. I don't think there is anything to do here on the Go side. Please comment if you disagree.

Are you suggesting that the changes referred to in #30099 (https://golang.org/cl/161202) have caused an improvement in this situation? If so, excellent :-)

They may have improved the situation. I don't know for sure.