time: add SetLocal

[georgmu]

I want to provide an API server which is capable of setting the system time zone.

After changing the system time zone, the running go process still uses the old timezone and it is not possible to refresh except restarting the process.

In java there is a java.util.TimeZone.setDefault() to switch the timezone of the VM. It would be nice to either provide something similar or to add a method to refresh the localLoc variable.

[nightlyone]

I wish there wasn't.

Timezones are basically an UI/display issue. If you know what is the "local" time zone, just convert your times to it instead of setting a global default.

[georgmu]

Well, there are certain services running on the machine that want to use the timezone to format their data. Thus, a central time zone setting for the host makes sense.
This is not about UI at first, but a sane default timezone representing the local time for a local use makes sense. UI is capable of converting this to an other timezone, if required

[Thomasdezeeuw]

I think you use UTC time at all times to communicatie between systems. This way you don't need to deal with these sort of issues.

[georgmu]

Well, I currently have this kind of an issue, and without a restart of the program, I am not able to solve it.

There are good reasons to have a system-wide time zone on a server. This might not be useful for services and system-to-system communication, but for the local system it is.

Even the default log.Println() uses the local timezone to format the date, but it does not react on time zone changes, nor is it possible to force a re-read of the local time zone. (and the default log.Println() does not print any timezone offset to "know" what time zone it is using currently)

[rsc]

I've updated the title. What you're asking for is

package time

// SetLocal changes the current meaning of time.Local to match loc.
func SetLocal(loc *Location)

I don't believe this is a good idea. In general but especially in Go, coordination via global mutable state is almost always a mistake and difficult to correct once you realize it.

If there are higher-level APIs that force the use of time.Local, we should probably address those instead. For example, if package log is what you are concerned about, it would probably be okay to file a separate issue for adding log.SetLocation and log.(*Logger).SetLocation.