> Bummer, I still like them better than json. :-) String stream only started to work with JS recently and still can't do pointer stuff. I wish binary formats was better supported in JS.
> There are cases where you want to store a (timestamp, timezone) tuple Exactly, I view timestamp as kind of a string and timezone kind of language code. If you need to store what language a string is in, yes store it. But most of the time that is not needed, and you just need to display time in the user's "language." > nimble removes the src directory I never had an issue with that. Maybe you need to use staticRead instead of readFile? > float64 for timestamp I still will stand for float64 timestamp for my application. Yes there are special places like banking that don't use float points. They are special. You would not use float points for money too. For almost every one else float64 since 1970 fits the bill. * Seconds is the SI time unit. Not using it is like using decameters or distance. Its just strange. * Seconds from 1970 works great as its when unix time started. * You can't use int64 in JS. Most of my work is in JS. You can't encode that in json. So you would have to use two numbers ... maybe seconds and microseconds? BigInt in json looks like a pain. * I interface with many systems and they give me random scaling. I always have bugs with this conversions. Even with nim, is sleep() in seconds, milliseconds, or microseconds? In python I always know its seconds. Because everything else is seconds. Python does it best. Just use single scaling, its not so hard! Here is what I deal with on daily bases > * python 1.0 > * java 1000 > * js 1000 > * bigquery 1000_000 > * go 1000_000_000 > That is why I use float64 seconds from 1970 utc. > leap seconds I should add a j2000 mode as that will enhance my [https://github.com/treeform/orbits](https://github.com/treeform/orbits) library.
