Golang application local timezone doesn't change with the system timezone

[E Z]

I noticed a phenomenon while maintaining my golang application, the local timezone of the application always keep the value when it starts, the local timezone will not change even though I change the system timezone. It looks like the golang time package has been caching the current timezone.

Is there any way to change the local timezone in the golang application as the system's timezone changes?

[Matthew Walster]

On Wed, 9 Feb 2022 at 23:36, E Z <lege...@gmail.com> wrote:

I noticed a phenomenon while maintaining my golang application, the local timezone of the application always keep the value when it starts, the local timezone will not change even though I change the system timezone. It looks like the golang time package has been caching the current timezone.

Is there any way to change the local timezone in the golang application as the system's timezone changes

See https://cs.opensource.google/go/go/+/refs/tags/go1.17.6:src/time/zoneinfo.go and https://cs.opensource.google/go/go/+/refs/tags/go1.17.6:src/time/zoneinfo_unix.go -- there is a sync.Once to set it. I would have thought changing the timezone underneath a running program would not be a good idea due to it often not being an atomic swap.

M

[Ian Lance Taylor]

On Wed, Feb 9, 2022 at 3:37 PM E Z <lege...@gmail.com> wrote:
>
> I noticed a phenomenon while maintaining my golang application, the local timezone of the application always keep the value when it starts, the local timezone will not change even though I change the system timezone. It looks like the golang time package has been caching the current timezone.
>
> Is there any way to change the local timezone in the golang application as the system's timezone changes?

htttps://go.dev/issue/28020

Ian

[E Z]

I find a way to work around.

The goal is to get the valid timezone of the system periodically in my application, So I try to get the valid timezone name from the file /etc/timezone and then parse it to the necessary object I need, to avoid accessing the file too often, I add a cache for the timezone.  It's not a perfect solution, but I think it's enough for my scenario.

[Carl]

I would like to  understand the reasoning for the implementation, if possible. 

Simple example:

I have a laptop running Ubuntu (or any other popular Linux distro).

I fly from New Zealand to Los Angeles

I open my laptop and change the timezone via the system GUI (which under the hood uses timedatectl which updates /etc/timezone and /etc/localtime)

If I had running services written in Go, they would not be aware of the timezone change.

Questions I have:

Why doesn't Go respect standard time zone changes?

Is there a recommended way to address this?

Cheers,

Carl

PS> 

I'm aware of https://github.com/golang/go/issues/28020 but would really like to know the reasoning behind caching the timezone and not invalidating the cache when it changes.

[Kurtis Rader]

On Tue, Mar 1, 2022 at 2:55 PM Carl <carl...@gmail.com> wrote:

I would like to  understand the reasoning for the implementation, if possible. 

Simple example:

I have a laptop running Ubuntu (or any other popular Linux distro).

I fly from New Zealand to Los Angeles

I open my laptop and change the timezone via the system GUI (which under the hood uses timedatectl which updates /etc/timezone and /etc/localtime)

If I had running services written in Go, they would not be aware of the timezone change.

Questions I have:

Why doesn't Go respect standard time zone changes?

Is there a recommended way to address this?

How would Go do that  

--

Kurtis Rader

Caretaker of the exceptional canines Junior and Hank

[Kurtis Rader]

On Tue, Mar 1, 2022 at 2:55 PM Carl <carl...@gmail.com> wrote:

I would like to  understand the reasoning for the implementation, if possible. 

Simple example:

I have a laptop running Ubuntu (or any other popular Linux distro).

I fly from New Zealand to Los Angeles

I open my laptop and change the timezone via the system GUI (which under the hood uses timedatectl which updates /etc/timezone and /etc/localtime)

If I had running services written in Go, they would not be aware of the timezone change.

Questions I have:

Why doesn't Go respect standard time zone changes?

Is there a recommended way to address this?

How would Go do that in a cross-platform manner?  Also, many long running programs may produce output (e.g., log files) where you don't want a TZ change to affect the output. Even if this capability were added to the Go stdlib it should be opt-in, not the default behavior.

[Robert Engels]

Have a background routine that polls the os every N secs - but the OP can do that themselves. 

On Mar 1, 2022, at 5:32 PM, Kurtis Rader <kra...@skepticism.us> wrote:



--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CABx2%3DD-xUMPXMy6WM_vf1O83mVV7TROam84uCJthRLnzjSY2cQ%40mail.gmail.com.

[Carl]

I'm interested in the reason for the current behaviour. 

I know there are ways to work around it and am aware of the consequences of a change to the stdlib now. 

I'm also aware of what will happen if the timezone changes on a standard system. 
I assume all platforms that Go supports support the ability to change the timezone without rebooting the system and they already handle it.

If that's the case, why does Go ignore the case that the time zone can change when a program is running? 

Please don't misunderstand me - I love Go and really respect the design decisions that went into the language.

This is why I'm interested in the reason for the current behaviour - to learn.

I would really appreciate a reply from someone who can provide the actual reason the time package was implemented this way.

[Robert Engels]

Yea - argument doesn’t hold much water. Log files either use timezonr agnostic times or the users know they will change if the time zone changes. 

On Mar 1, 2022, at 6:05 PM, Carl <carl...@gmail.com> wrote:

I'm interested in the reason for the current behaviour. 

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/92c53e08-b24d-42a1-bba5-88ac55c91fafn%40googlegroups.com.

[Ian Lance Taylor]

On Tue, Mar 1, 2022 at 4:05 PM Carl <carl...@gmail.com> wrote:
>
> I'm interested in the reason for the current behaviour.
> I know there are ways to work around it and am aware of the consequences of a change to the stdlib now.
> I'm also aware of what will happen if the timezone changes on a standard system.
> I assume all platforms that Go supports support the ability to change the timezone without rebooting the system and they already handle it.
>
> If that's the case, why does Go ignore the case that the time zone can change when a program is running?
>
> Please don't misunderstand me - I love Go and really respect the design decisions that went into the language.
> This is why I'm interested in the reason for the current behaviour - to learn.
>
> I would really appreciate a reply from someone who can provide the actual reason the time package was implemented this way.

I don't think there is any mystery about it. It's the simplest way to
implement the time package. Additional mechanism to detect that the
timezone has changed and use the new timezone is increased complexity.

That's not to say that we shouldn't change it (as I said above, that
is https://go.dev/issue/28020). But it's actually not all that
obvious how to change it. We certainly don't want to check the local
timezone every time that a program asks for the current time; that
would be a measurable performance cost for a case that approximately
never happens.

Ian

[Carl Menezes]

Thanks. Makes sense.

Cheers,

Carl

[Brian Candler]

On Tuesday, 1 March 2022 at 22:54:35 UTC carl...@gmail.com wrote:

If I had running services written in Go, they would not be aware of the timezone change.

I think the current behaviour is reasonable, because it's rare that a running, persistent *service* needs to know of a change of the *system* timezone.

If this is a web server interacting with a user, then either it should use the browser timezone, or have a user preference for timezone.  If it's writing log files then it should be using UTC or a chosen fixed timezone (otherwise there's ambiguity about what time events happened).  If it's talking to a database with date/time columns, the same applies.

[Roland Müller]

Hello,

Yes, I agree. In rare cases when a service has to re-evaluate its settings it should be the responsibility of the program changing the configuration to initiate reloading settings or re-starting the service.

How to do that is dependent on the operation system:

* In the old times on Unix or Linux a HUP signal was send to inform a service (=daemon) to re-read its configuration and maybe to restart. In systemd the systemctl reload command could be used. 

* for Windows I have no idea

BR,

Roland

 

--
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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/7bc6b39e-9b60-4ae6-9df1-f8a2abceb0bcn%40googlegroups.com.