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

--

Search Discussions

  • Sameer Ajmani at Dec 1, 2012 at 2:55 am
    Doesn't float64(d)/float64(time.Millisecond) work?
    On Nov 30, 2012 7:49 PM, 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 at Dec 1, 2012 at 4:42 pm
    int64(d/time.Millisecond)

    will convert the duration into an int64 number of milliseconds.

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

    On Fri, Nov 30, 2012 at 8:59 PM, Sameer Ajmani wrote:

    Doesn't float64(d)/float64(time.Millisecond) work?
    On Nov 30, 2012 7:49 PM, 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,

    --

    --

    --
  • Rémy Oudompheng at Dec 1, 2012 at 4:38 pm

    ON 2012/12/1 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 at Dec 2, 2012 at 11:52 am
    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)

    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,
    --
  • Sylvain Defresne at Dec 6, 2012 at 10:26 pm
    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,
    On 2 Dec 2012 11:52, "Peter" wrote:

    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)

    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,
    --
  • Rémy Oudompheng at Dec 6, 2012 at 10:30 pm

    On 2012/12/6 Sylvain Defresne 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.

    --
  • Boslandm at Dec 6, 2012 at 11:12 pm
    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.

    If we have Hours, Minutes, Seconds, Milliseconds and Microsecond constants
    (which we do) then why do we not have Millisecond and Microsecond methods,
    yet we do for the other constants?

    I'm not recommending Deciseconds here. :) If we care enough about
    providing a Millisecond constant, I think we should provide a Millisecond
    method.

    Case in point. Look how many ways people in this single thread have
    expressed Milliseconds of duration.
    On Thursday, December 6, 2012 10:30:16 PM UTC, Rémy Oudompheng wrote:
    On 2012/12/6 Sylvain Defresne <sdef...@google.com <javascript:>> 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 at Dec 6, 2012 at 11:13 pm
    It seems fine to me.

    --
  • Bryanturley at Dec 7, 2012 at 5:05 pm

    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.

    --

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedDec 1, '12 at 12:49a
activeDec 7, '12 at 5:05p
posts10
users8
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase