sqlean-time
Data
sqlite extension
SHOW HN2024
How HN took it
1 positive, 12 neutral or asking, 0 mixed, 9 critical, out of 22 comments about the project. Thread score -0.20.
Design: 0 for, 4 againstExecution: 0 for, 3 againstIdea: 1 for, 2 against
The thread, comment by comment
Each row is a top-level comment and its replies, in HN's order. Select a cell to open that comment on HN.
positive neutral or mixed critical about another commenter or something else the maker
What HN said
What people liked
Useful missing feature for SQLite
From 1 comment
Very cool - definitely an important missing feature in SQlite.
simontheowl on HN
Objections
Only fixed time zone offsets, no time zone names or local time
From 2 comments
This library doesn't deal with the notion of local time at all. It's all UTC-based times, possibly with a user-supplied timezone offset, but then the hard part of calculating the…
sltkr on HNThanks for the suggestion! True, only fixed offsets are supported, not timezone names.
nalgeon on HN
Ignores leap seconds
From 1 comment
> It's all UTC-based times Not even that. UTC has leap seconds, which this code doesn’t handle (FTA: “The calendrical calculations always assume a Gregorian calendar, with no…
Someone on HN
Nanosecond precision limits range to about ±290 years
From 1 comment
I find the three different time representations/sizes curious (eg, what possible use case would need nanosecond precision over a span of billions of years?). More confusing is…
mynameisash on HN
Requests
Handle historical timezone changes and local time discontinuities
From 2 comments
Does this handle the special case of timezone changes (and local time discontinuity) that Jon Skeet famously documented?…
alberth on HN@nalgeon Do you plan to address the use cases in the SO post, or asked differently - what is the intended use case of this library? I tried to recreate it on your site (which is…
alberth on HN
Questions
Why use nanosecond precision and a limited range
From 2 comments
I find the three different time representations/sizes curious (eg, what possible use case would need nanosecond precision over a span of billions of years?). More confusing is…
mynameisash on HNThis is a sort of lazy Ask HN: but in your experience, what is more useful / valuable - nanosecond representation, or years outside the nano range of something like 1678-2200 I…
lifeisstillgood on HN
Is the SQLite ecosystem the right target
From 1 comment
Another POV is, why build for the SQLite "ecosystem" at all?
doctorpangloss on HN
Alternatives named
Unix timestamps as signed int64 nanoseconds
From 1 comment
Why not go golang style, unix timestamp as nanoseconds, in signed int64. Maybe you can't cover millions of years with nanosecond precision, do you really need it?
out_of_protocol on HN