[Someone]

> 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)

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.

[nottorp]

> 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]

A 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_prop...)

[doctorpangloss]

Another POV is, why build for the SQLite "ecosystem" at all?

[devmor]

Probably 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]

SQLite is the most widely used database in the world. Full stop.

[raggi]

after a few things like hosts files which exist on every major operating system including windows

[vsuperpower2021]

You can find dozens of SQlite databases on a single phone if you want to be pedantic