> > The sec and nsec fields in a time.Time are relative to the Unix epoch
> and so
> > denote a point in time by themselves. The location is merely for
> > presentation.
> Pedantically, they are not relative to the Unix epoch. They are
> relative to January 1, year 1, 00:00:00.000000000 UTC.
Thanks everyone for the various responses.
I suspect my inclusion of a potential definition of the struct behind the
type time.Instant has confused what I was trying to get at.
All I had intended with time.Instant is that a value of type time.Instant
should represent an instant in time with a specific precision (time.Time
defines this precision as nanoseconds), which I believe only requires us to
define time (and the precision), a definition we get from UTC (and second). *A
corollary of this point, I don't understand why UTC is considered a
location... but maybe that's a separate point.*
time.Instant would likely only define Unix() and UnixNano() methods. And
this deals with your point about "correctness" Axel, because you wouldn't
be able to do anything presentational with a value of type time.Instant,
instead you'd rely on:
func FromInstant(inst Instant) Time
at which point you're "safe" again. But your point about trying to avoid
mistakes when handling time, zones etc is well received; that is dealt with
elsewhere in my case.
The implementation of time.Instant is of course arbitrary... although I
would imagine it's likely to follow the approach currently used by
time.Time, hence why I included the struct definition.
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.