4 ms·
> 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 ca
by Someone 2y ago
> 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 leap seconds”)
It copies that from the golang time package, which makes the same claim (https://pkg.go.dev/time https://pkg.go.dev/time)
That makes life a lot simpler for the implementer, but doesn’t that mean you can only reliably use these two libraries for computing with durations, not with moments in time or vice versa? The moment you start mapping these times to real world clocks and adding durations to them, you run the risk of getting small (up to about half a minute, at the moment) inconsistencies.
- doctorpangloss 2y agoAnother POV is, why build for the SQLite "ecosystem" at all?
- devmor 2y agoProbably because SQLite is one of (if not THE most) widely used database implementations for IoT software in the world. That’s like asking why someone made a package for javascript.
- ErikBjare 2y agoSQLite is the most widely used database in the world. Full stop.
- raggi 2y agoafter a few things like hosts files which exist on every major operating system including windows
- vsuperpower2021 2y agoYou can find dozens of SQlite databases on a single phone if you want to be pedantic
- nottorp 2y ago> The calendrical calculations always assume a Gregorian calendar, with no leap seconds. That could drift a bit if you can represent a 580 million year interval (with millisecond precision), wouldn't it?
- Someone 2y agoA library that handles leap seconds can’t do much better, as it’s as good as impossible to predict leap seconds, certainly not that far ahead. Luckily, leap seconds are on the way out (https://en.wikipedia.org/wiki/Leap_second#International_proposals_for_elimination_of_leap_seconds https://en.wikipedia.org/wiki/Leap_second#International_prop...)