vlib: time.Duration and `-` operator leaves spurious ns reminder for a - b < 0 case. about v HOT 4 CLOSED

Does not seems a bug to me. The time.now() has ns but the time.parse result does not. So obviously will be the delta there.

from v.

Subtracting one time value from another returns a Duration, which is just an i64 number of nanoseconds.

You're converting that to an int, which is what gives you the crazy number of seconds.

Now... that said, it doesn't appear that the - function is working correctly, as it should be a whole lot more nanoseconds than what's being shown.

Here it is without the cast (or shelling out to cowsay...):

import time

now := time.now()
then := time.parse("2024-03-06 17:28:00")!
delta := then - now
println('ETA: ${delta} or ${delta.seconds()} seconds')

With that change I get

ETA: -924ns or -1.399575694117924e+06 seconds

(of course, different numbers every time)

Those numbers hardly look correct.

from v.

I think you are correct. I am probably looking for a Unix now timestamp with a second resolution.

However, there seems still to be an issue with the display (to string) method for negative durations. I am confused at least.

    now := time.now()
    then := time.parse("2024-03-06 17:28:00")!
    delta := then - now
    seconds := int(delta.seconds()) // this will be plenty, but ${delta} will only give negative ns fraction
    os.system("echo ETA: ${delta} or ${seconds} seconds | cowsay")

 ________________________________
ETA: -796ns or -693579 seconds >
 --------------------------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

( I wrote this on the train so my son would not have to ask me when we arrive at our destination... ) ;-)

from v.

The somewhat spurious output fromthe string representation made me think that Durations were limited to non-negatives. I think this was just an error in how they are represented as strings.

from v.