Thanks. Makes sense. Cheers, Carl
On Wed, Mar 2, 2022 at 1:09 PM Ian Lance Taylor <i...@golang.org> wrote: > On Tue, Mar 1, 2022 at 4:05 PM Carl <carle...@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 > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CACPu_hXZBLvswxTOQoTu4jX6n8PXNr5aJ6fHaMgBkANytPF6Zg%40mail.gmail.com.
