I am aware. I don't understand how that contradicts my point that they have
an implied location (or rather *Location, namely time.UTC).

I am aware, that you could choose an arbitrary *Location (because that's
what time.UTC is. Just one, arbitrary, timezone) and create a special
in-memory Representation for times relative to that *Location. It still
doesn't seem worthwile to me and likely to cause more trouble than it has
advantages.

On Wed, Sep 21, 2016 at 8:55 PM, Jakob Borg <ja...@nym.se> wrote:

> 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