Re: [go-nuts] time.Time vs time.Instant
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 :
> 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 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 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.
Re: [go-nuts] time.Time vs time.Instant
> > > 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.0 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.
Re: [go-nuts] time.Time vs time.Instant
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 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 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.
Re: [go-nuts] time.Time vs time.Instant
On Wed, Sep 21, 2016 at 1:55 PM, Jakob Borg 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. Right, making your "instant" a duration with an implicit starting time, and a time that has a timezone at that (aka, just a duration that we've made some arbitrary assumptions about, which you could do with the existing duration implementation). —Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 -- 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.
Re: [go-nuts] time.Time vs time.Instant
Ah, indeed. No pedantry required to appreciate the difference, it's almost two thousand years after all. :) Sorry for the confusion. //jb ons 21 sep. 2016 kl 21:40 skrev Ian Lance Taylor : > On Wed, Sep 21, 2016 at 11:55 AM, Jakob Borg 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. > > Pedantically, they are not relative to the Unix epoch. They are > relative to January 1, year 1, 00:00:00.0 UTC. > > Ian > -- 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.
Re: [go-nuts] time.Time vs time.Instant
On Wed, Sep 21, 2016 at 11:55 AM, Jakob Borg 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. Pedantically, they are not relative to the Unix epoch. They are relative to January 1, year 1, 00:00:00.0 UTC. Ian -- 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.
Re: [go-nuts] time.Time vs time.Instant
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 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.
Re: [go-nuts] time.Time vs time.Instant
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 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.
Re: [go-nuts] time.Time vs time.Instant
On Wed, Sep 21, 2016 at 11:22 AM, Paul Jolly 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.
I don't know if that was ever considered.
I expect that part of the reasoning is that most operating systems
don't give you a way to get an instant in time, separate from a
location. They just tell you what time it is in the system timezone,
time.Local.
Ian
--
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.
