4 ms·

It works very well for me and thousands of other Go developers. That's why I chose this approach.

g15jv2dp 2y ago
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.
- nalgeon 2y ago
  [flagged]
  - g15jv2dp 2y ago
    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.
  - marcellus23 2y ago
    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
    - deleted 2y ago
      [deleted]
      - deleted 2y ago
        [deleted]
  - goldfishgold 2y ago
    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.
    - ncruces 2y ago
      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).
bongodongobob 2y ago
Nice. Smoking cigarettes works for me and millions of others but it's still stupid and will take years or decades of your life.

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.

nalgeon 2y ago
[flagged]
- g15jv2dp 2y ago
  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.
- marcellus23 2y ago
  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
  - deleted 2y ago
    [deleted]
    - deleted 2y ago
      [deleted]
- goldfishgold 2y ago
  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.
  - ncruces 2y ago
    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).

bongodongobob 2y ago

Nice. Smoking cigarettes works for me and millions of others but it's still stupid and will take years or decades of your life.