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.

ons 21 sep. 2016 kl 20:35 skrev 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com>:

> Your Instant is not an Instant, it's a duration. For a duration to
> demarkate an Instant, you'd actually need a reference point (a zero). And
> that'll pretty much certainly be given relative to a location. So even your
> Instant still has a location, it's just implied (probably to be UTC).
>
> Personally, I *really* like how the time.Time design doesn't let you
> forget that what you have is inherently a clock and the instant in time
> that is marked by that clock depends on it's location. Too much software
> out there is coming from exactly your PoV: Dealing with unix-timestamps in
> the belief that they are sufficient to mark a point in time. But then,
> during transmission, storage, bugs or accidental reinterpretation, you
> loose that information or add it where it doesn't belong and that's how
> timezone-bugs are born.
>
> By making it impossible to separate the two, go forces you to consider
> that all the time. Which is, in my opinion, a good thing. That you get for
> very little overhead.
>
> On Wed, Sep 21, 2016 at 8:22 PM, Paul Jolly <p...@myitcv.org.uk> wrote:
>
>> Please can someone can enlighten me or point me towards relevant
>> docs/other regarding the design decisions behind time.Time?
>>
>> Specifically why the concept of an instant in time, referenced many times
>> throughout the time docs, was not encoded as a type itself:
>>
>> type Instant struct {
>>     sec int64
>>     nsec int32
>> }
>>
>> and time.Time then reference time.Instant in some way:
>>
>> type Time struct {
>>     instant Instant
>>     loc *Location
>> }
>>
>> The obvious difference being that an instant in time has no location. If
>> I'm only interested in instants in time (i.e. my code doesn't do anything
>> presentational) then the location is redundant.
>>
>> Many thanks
>>
>>
>> --
>> 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.
>>
>
> --
> 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.
>

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