> I don't think the same issues apply to timestamps
the moment you're using FP as your internal internal representation you're
affected by FP semantics and the machine epsilon, eg:
* catastophic cancellation problem:
var a = 1.2
var b = a + 1e14
var c = b - 1e14
echo (a, c, a == c)
Run
(1.2, 1.203125, false)
even with a 10% range of variation you still can't rely on timestamp equality:
var a = 0.1
var b = a + 1
var c = b - 1
echo (a, c, a == c)
Run
(0.1, 0.1000000000000001, false)
There's a good reason almost all datetime libraries use fixed point/integral
arithmetics internally to represent time instead of FP: C (ctime), C++
(std::chrono, boost date_time), mongodb (int64 milliseconds since epoch), D
([https://dlang.org/phobos/std_datetime_systime.html)](https://dlang.org/phobos/std_datetime_systime.html\)),
and in particular nim: Time = (secs: int64,nsecs: int)
> IMHO that contributes to making the library super awkward to use; you have to
> invoke a manual conversion function to cast times to different units.
that's a C++ problem; nim doesn't have this problem. Look at the std/times
module which abstracts the internal representation as (secs,nsecs)
float may be easier on first sight from implementer point of view (not for user
point of view), but it just causes more problem.
I even added fromUnixFloat+ toUnixFloat in
[https://github.com/nim-lang/Nim/pull/13044](https://github.com/nim-lang/Nim/pull/13044)
so you can convert your user FP timestamps into internal std/Time (int64,int)
representation and then just deal with internal representation for all
operations.
It gives you nanosecond precision within +/\- 300 billion years, so you can
represent any nanosecond in the universe's timespan and well beyond, without
any loss or catastrophic cancellation issues, and reliable timestamp equality.
# js support
for js, BigInt is IMO the right approach; i'ts supported in almost all browsers
except for IE (which is EOL'd anyway) and safari (which is "hopefully almost
there not giving up hope", see
[https://bugs.webkit.org/show_bug.cgi?id=179001](https://bugs.webkit.org/show_bug.cgi?id=179001)
which has almost all dependent issues fixed); and there are polyfills eg
[https://github.com/peterolson/BigInteger.js](https://github.com/peterolson/BigInteger.js)
