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. 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/CAOyqgcXueyJ1H-wDvKNYyO40ZM3r0pTs6ibNDYzHnNXaC_aGSA%40mail.gmail.com.
