UTC, Coordinated Universal Time, is not really an arbitrary time zone. It's
the time scale underlying almost all time measurements on Earth (excepting
some specific use cases, typically in astronomy) and from which all time
zones are derived. As such, I don't think it implies a location (other than
"on Earth", possibly).
Having a defined time scale is necessary when talking about a point in time
as a duration relative to another well defined reference point. I'm not
aware of any other common way of denoting points in time other than as a
duration from a reference point, so I'm not sure what's the significance of
the difference between a point in time and a duration? Perhaps it's
philosophical. :)
//jb
ons 21 sep. 2016 kl 21:49 skrev Axel Wagner <axel.wagner...@googlemail.com>:
> 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.
