Mirror of forum.nim-lang.org

6966 :: Convert Time to Duration

• wilypomegranate (orginal) [2020-10-21T04:20:17+02:00] view original

  Nim noob here.

  Is this valid? Is there a better way?

  let myDuration = cast[Duration](getTime())
  Run

---

• ElegantBeef (orginal) [2020-10-21T05:53:55+02:00] view original

  In Nim the cast operation is for reinterpretting a type as another, type conversions are done.

  float(anInt)
  anInt.float #thanks to ufcs
  Run

  It also seems duration is meant for offseting/finding the difference between time.

---

• xigoi (orginal) [2020-10-21T08:41:59+02:00] view original

  It doesn't make sense to “convert” a duration into a timestamp, they're completely different concepts. If you want to get the timestamp that comes the given duration after another timestamp, just add them with +.

---

• Leaf (orginal) [2020-10-21T11:29:39+02:00] view original

  First of all is, what do you want?

  Do you want a timestamp, a duration, how a cast work, the 'let' statement, something with time or all together?

  Have a look at here: https://nim-lang.org/docs/times.html#Duration (To create a new Duration, use initDuration proc.)

  proc initDuration https://nim-lang.org/docs/times.html#initDuration,int64,int64,int64,int64,int64,int64,int64,int64

  and an example here: https://docs.w3cub.com/nim/times/

  In Google type in: Nim Duration. (only as help, first the word Nim and what you are searching. Sometimes is difficult to find something. Is not Python :-) )

---

• cblake (orginal) [2020-10-21T11:50:59+02:00] view original

  A timestamp is just a duration since an origin, like the epoch time since Jan 1, 1970. times lets you create one easily, though. You can just say

  let dur = initDuration(seconds=3600*24*10_000)
  Run

  to get a Duration-typed interval of 10,000 days since Jan 1, 1970.

---

• wilypomegranate (orginal) [2020-10-22T01:55:35+02:00] view original

  So the case I'm interested in, is I have a Time(or DateTime) type and want to get what it's epoch nanosecond representation as an integer. Seemed like converting to a duration and doing inNanoseconds on it was the easiest way.

---

• wilypomegranate (orginal) [2020-10-22T02:03:39+02:00] view original

  Okay seems like I should not do that then:)

---

• shirleyquirk (orginal) [2020-10-22T03:33:30+02:00] view original

  To get elapsed nanoseconds since the epoch you can

  import times
  proc epochNanos(t:Time):int64=
    t.toUnix*1_000_000_000 + t.nanosecond
  echo getTime().epochNanos
  Run

---

• xigoi (orginal) [2020-10-22T07:14:17+02:00] view original

  There are functions toUnix and toUnixFloat. Both return Unix time in seconds, the latter as a float with sub-second resolution.

---

• wilypomegranate (orginal) [2020-10-22T13:50:00+02:00] view original

  toUnixFloat isn't right for my use case. The answer using t.nanosecond works.

  import times
  proc epochNanos(t:Time):int64=
    t.toUnix*1_000_000_000 + t.nanosecond
    echo getTime().epochNanos
  Run

---

• Yardanico (orginal) [2020-10-25T08:59:32+01:00] view original

  2262 is a bit too far away :)

---

• xigoi (orginal) [2020-10-25T11:13:02+01:00] view original

  That's what people said about 2000. :)

---

• Yardanico (orginal) [2020-10-25T11:14:17+01:00] view original

  Well, yes, but 2262 isn't 50 years away, not even 100

---

• xigoi (orginal) [2020-10-25T11:37:36+01:00] view original

  What if the software is used by astronomers for making long-term calculations?

---

• SolitudeSF (orginal) [2020-10-25T12:10:14+01:00] view original

  they are going to use dedicated library, not general purpose

---

• cblake (orginal) [2020-10-25T13:24:45+01:00] view original

  Astronomers also do not care about ns precision on century forecasts/backcasts. ms precision or even second precision can be overkill. The same is likely true of any long-time-range interest. 64 bits is "numerically plenty", though two..four distinct scales may make sense, and in at least specialized types if not specialized whole libraries.

---

• cblake (orginal) [2020-10-25T13:29:02+01:00] view original

  Also, using floating point at all can slow down your entire system. E.g., Linux will skip save/restore of big register sets/CPU state until code "dirties" the FP state. This makes all context switches faster. So, when timing/benchmarking, if possible it is better to use 64-bit ints right up until you need to print some number, perhaps at the very end of a process' execution. At least the API should not force you to use float. You may never need it period.

---

• jackhftang (orginal) [2020-10-25T14:48:25+01:00] view original

  You are right that it is not suitable to use the timestamp library if the use case beyond time bound from 1677-09-21T00:12:43.145Z to 2262-04-11T23:47:16.854Z

  It is more plausible to use the library for time-series data which usually just the time of measurements and a lot for data points collected over time. So a compact and fast time representation of time is more flavourful.

---

• slonik_az (orginal) [2020-10-26T00:06:41+01:00] view original

  64 bits is "numerically plenty",

  Numpy took an approach of timedelta64 that supplants 64-bit integer with units (Y,M,D,h,...ms,us,ns...) creating a balance between time span and resolution. Nim can do it more elegantly using distinct int64 types and converters.

---