Hi Ian,

> The argument here
is that a program would only call the UTC method if it wants to change
the way that those conversions work, so it presumably cares about the
wall time, not monotonic time.

But in those contexts, the monotonic time wouldn't make a difference - so
what is the upside of stripping it? Are there cases I'm not seeing where
the mono time would interfere with these "standard" usage patterns?

Thanks,
-Radu

On Wed, Oct 27, 2021, 4:01 PM Ian Lance Taylor <i...@golang.org> wrote:

> On Wed, Oct 27, 2021 at 3:37 PM Andrei Matei <and...@cockroachlabs.com>
> wrote:
> >
> > 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, 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()).
>
> A time.Time value always represents an instant in time to nanosecond
> precision, and the specific instant that it represents is independent
> of the timezone.  The only effect of changing the timezone is that it
> changes the way that the time.Time converts to other representations,
> via methods like String or Format or Date or Clock.  The argument here
> is that a program would only call the UTC method if it wants to change
> the way that those conversions work, so it presumably cares about the
> wall time, not monotonic time.  I understand that that is not true in
> your case.  The argument doesn't always hold.  But it often does.
>
> 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/CAEthiYDDJker4h1Zr%2BtuB4aurnAP_SzYRWPdLyKmjTMUQij8sw%40mail.gmail.com.

Reply via email to