The title of the article is "Micro-libraries need to die already". Renaming the submission to "Micro-libraries should never be used" is pathetic, Daniel. I'm not surprised though.
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 very cool btw in allowing the code to run in browser) and it seems to fail and give the wrong time difference.
Please don't take my comments as being negative or unappreciated, this is super difficult stuff and anyone who tries to make the world an easier place should be thanked for that. So thank you.
As discussed in the top-level comment, this library has no concept of timezones (only offsets) so the SO link does not apply. The time rollback only happened in Asia/Shanghai.
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
m := map[string]int{"a": 1, "b": 2, "c": 3}
for k, v := range maps.All(m) {
fmt.Printf("%v:%v ", k, v)
}
fmt.Println("")
for k, v := range m {
fmt.Printf("%v:%v ", k, v)
}
These both output the same thing. What's the point of the addition?
Slices.All() seems similarly redundant and pointless.
Surely I must be misunderstanding something, I hope.
They’re useful because they let you pass a slice or map to something built to handle the new func(func (…) bool) style iterators.
If I create a IterateOver(fn func(func (K, V any) bool)) function, you cannot pass a slice since that doesn’t match fn’s type, but if you wrap it with slices.All it’ll work.
