Please give some examples of what you would like to see. Thanks.

As far as I can see the list of IANA timezone names is quite long and subject to regular change: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones .

loc, err := time.LoadLocation(time.Asia_Shanghai)
Something like that.

Does the location names change frequently? If that's the case I see the problem

The timezone database updates frequently. To update timezone database the Go team can release it with each Go version or create a mechanism to update it with go get (better option I think)

But why is LoadLocation(time.Asia_Shanghai) better than LoadLocation("Asia/Shanghai") ?

But why is LoadLocation(time.Asia_Shanghai) better than LoadLocation("Asia/Shanghai") ?

Because of autocompletion. In first approach there will be compile time error and in the second one there will be error in run time

The problem is that we read timezones data from the system database, and we support the timezones names and abbreviations we read from the system... So if, for example, we include Asia_Shanghai in the enum but then Asia/Shanghai is not in the timezones db the call will fail at runtime anyway.

And what happens if a name is removed from the DB? We can't remove it from the enum without breaking backward compatibility.

My point is that it's probably not worth having compile-time checks (in the form of a fixed enum) on something that is gonna be dynamic anyway like timezones data (which is dynamic because as I wrote we read the data at runtime from the system database).

My point is that it's probably not worth having compile-time checks (in the form of a fixed enum) on something that is gonna be dynamic anyway like timezones data (which is dynamic because as I wrote we read the data from the system database, at runtime).

Yes, you are right, there are tradeoffs in both side, I just added this issue for discussion, I wanted to know other people's opinion about what was better

Since we get the timezone information from the local system, I agree that it would be unfortunate to define enum values for timezones that are not necessarily supported.