On Tue, Oct 26, 2021 at 6:09 PM Ian Lance Taylor <i...@golang.org> wrote:
> On Tue, Oct 26, 2021 at 2:07 PM Andrei Matei <and...@cockroachlabs.com> > wrote: > > > > If you accept that there are reasons for setting TZ for a particular > program, then > > would you also agree that there are reasons for wanting to do the same > from inside > > the program? We distribute our software for others to run, so we don't > generally have > > control / would rather not rely on the environment. > > > > Alternatively, if we can get (a flavor of) Time.UTC() to not strip the > mono any more, > > I'd also be happy with that. > > It's not obvious to me how common it is for a program to require that > all times be in UTC, but be unable to control that at the point where > the time.Time value is converted to some other type. If this is > common, then perhaps Go should provide some solution. But is it > common? > > There is already a mechanism for setting TZ from inside the program, > but as you've observed there is no mechanism that will ensure that > that happens before the possibility that package initialization > fetches the current time zone. It seems unlikely that Go would add > this feature, given that it's easy to use a tiny wrapper program to > set TZ and then invoke the real program. > > Personally I think that a version of UTC that doesn't strip the > monotonic time is solving the problem at the wrong end. The end that > matters is the conversion out of time.Time, not the creation of a > time.Time. > Fair enough. At least for my edification, though, I would benefit from a commentary about *why* exactly it is that UTC() strips the monos, if you happen to understand it. The only thing comment on the topic I found is here <https://github.com/golang/go/issues/18991#issuecomment-278446441>, from Russ: He said: > I should check on In, Local, UTC too. The argument for stripping in > those cases is that you're in some sense explicitly asking to work in wall times. I don't quite see that argument. Calling UTC() is not "explicitly asking to work in wall times". At least, that's not exactly the interpretation in our codebase. I would argue for a more limited interpretation: the call to UTC() should do something for the contexts in which a timezone is relevant, but I don't quite see why it does something (detrimental) for contexts where it's not relevant (i.e. time.Since()). Thanks! - Andrei > > 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/CAPqkKg%3D9BsAOi1b_du29fQdwcGFgORTcmFAyTCtbGV%3DfEeci%3Dg%40mail.gmail.com.
