>
> > 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.


Paul

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Reply via email to