There's no reason it wouldn't "work", the question is "why". Having such precise dates obviously comes with some compromises (e.g., the representation is larger, or it's variable depending on the value which comes with additional complexity, etc.). So surely there must be some pros to counterbalance the cons. "Because it's what Go does" is an answer, but I don't know if it's a convincing one.
WTF. I'm interested in what you've created and want to understand the reason for your design decisions, and this is how you reply?
edit: Well, it seems that the parent comment has been edited. But honestly, after reading the initial comment, I'm not interested in engaging in any way whatsoever with this person.
There's nothing in the linked blog post justifying why you might want a higher precision time. In fact the blog post would benefit from an explanation that outlines the current datetimes in sqlite and why they're insufficient.
Internally, SQLite uses milliseconds since the Julian day epoch stored as an 64-bit integer for date math, and uses the proleptic gregorian calendar (no leap seconds).
Externally, it uses either (a subset of) ISO 8601 with millisecond precision for a textual representation, or a IEEE 64-bit float representing either days since the Julian day epoch, or seconds since the Unix epoch.
You can also use integer seconds since the Unix epoch, but you'll get outside the supported date range before you use 53-bits, so 64-bit floats are equally safe.
The supported date range, btw., is from JDN zero through 9999-12-31T23:59:59.999.
In the 21st century, both of these representations can store the correctly rounded millisecond.
SQLite accepts time zone offsets, but immediately converts all times to UTC (or local time) and does not store the offset, so date functions can only output UTC or local time (no other time zone or offset).
I think you're being overly defensive. The GP is curious about the decisions you made, and just asking questions in a bit of a blunt (but not rude or accusatory) style that's typical for HN.
edit: the comment I'm responding to was much more vitriolic, it's since been edited
