Re: [go-nuts] Adding Duration.Microseconds() and Duration.Milliseconds() to time package

[Sameer Ajmani]

Doesn't float64(d)/float64(time.Millisecond) work?

On Nov 30, 2012 7:49 PM, <sdef...@google.com> wrote:

Hi,

When I want to get a duration in milliseconds with sub-millisecond precision, I currently have to do:

d := time.Since(start)

msec := d.Seconds() * float64(time.Second/time.Millisecond)

My other option is to use the Nanoseconds() method that return an int64, convert to float64 and then scale.

I'd like to introduce two methods Microseconds() and Milliseconds() that return float64.

// Microseconds returns the duration as a floating point number of microseconds.

func (d *duration) Microseconds() float64

// Milliseconds returns the duration as a floating point number of milliseconds.

func (d *duration) Milliseconds() float64

There are already Microsecond and Millisecond constants, and method to convert a Duration to all the other exported multipliers (Nanosecond, Second, Minute, Hour). I think we should at least provide them by symmetry.

What do people think of my suggestion? If nobody objects, I'd probably write the method and send the code for review.

Cheers,

--
 
 

[Kyle Lemons]

int64(d/time.Millisecond)

will convert the duration into an int64 number of milliseconds.

http://play.golang.org/p/IqRjYJ3JvN

--
 
 

[Rémy Oudompheng]

ON 2012/12/1 <sdef...@google.com> wrote:
> Hi,
>
> When I want to get a duration in milliseconds with sub-millisecond
> precision, I currently have to do:
>
> d := time.Since(start)
> msec := d.Seconds() * float64(time.Second/time.Millisecond)

Why not use "d.Seconds() * 1000" ?
Although it is true that the underlying integer value of time.Second
may change in a later version of Go, it seems reasonable that the
value of time.Second / time.Millisecond is not going to change.

Rémy.

[Peter]

May I ask why you need to measure something in milliseconds?

Unless you're formatting output, it may be more beneficial to stick with the Go idiom of using Nanoseconds everywhere, or just leaving things as time.Duration.

On Friday, 30 November 2012 23:03:42 UTC, sdef...@google.com wrote:

Hi,

When I want to get a duration in milliseconds with sub-millisecond precision, I currently have to do:

d := time.Since(start)

msec := d.Seconds() * float64(time.Second/time.Millisecond)

[Sylvain Defresne]

Yes, this is for display. Personally I find that reading that something took 23.65ms is easier to read than 0.02365s.

I know that I can use d.Seconds() * 1000 (or other variations, the factor is probably not going to change soon) and that a d.Milliseconds() method is probably redundant but so are d.Minutes() or d.Hours() (with factor of 1/60 and 1/3600).

Apparently most of the people think this is not needed, so I'll just keep them in my own util library. Thank you all for the opinions.

Regards,

[Rémy Oudompheng]

On 2012/12/6 Sylvain Defresne <sdef...@google.com> wrote:
> Yes, this is for display. Personally I find that reading that something took
> 23.65ms is easier to read than 0.02365s.

That's true, and that's why it's implemented in the standard library.
(http://play.golang.org/p/UUL2122urE)

package main

import (
"fmt"
"time"
)

func main() {
d := time.Millisecond * 2365 / 100
fmt.Println(d)
}

displays "23.65ms", not "0.02365s".

Rémy.

[David Symonds]

It seems fine to me.

[bryanturley]

On Thursday, December 6, 2012 5:12:26 PM UTC-6, bosl...@google.com wrote:

Does anyone object to the proposal to add methods Milliseconds and Microseconds?

I know that Go is trying to be minimalist and certainly those two aren't needed.  However, continuing that logic why are there Hours and Minutes?  They're certainly easily calculable in exactly the same ways as described as above.

There is a difference between minimalist and incomplete.  No offence intended to anyone ;)
I would guess it was just overlooked or put off seeing as it isn't really critical.