Agreed, though the topic of timezone+DST support has come up a few times in the SQLite forums, and the SQLite team has never expressed much interest in it. Which I don't blame them, they would need to write it from scratch in C (for licensing reasons), and keep a timezone DB updates, which sounds like a nightmare.
I'm curious - do you find yourself constrained by the default macOS build often? Typically I `brew install sqlite` and use that CLI to get around extension loading issues (and for more modern SQLite versions). Same with Python's default MacOS build, which I avoid at all costs. Though very curious to hear more about times where that isn't a viable option
> do you find yourself constrained by the default macOS build often?
Only for about 10 minutes after a new install until I ...
> `brew install sqlite`
But I could understand that some people may not have that option (although I've yet to work at a place that locks macOS down that much, I've worked at places which locked down their Windows laptops down far more than that.)
Often SQLite is what you will get, quite anywhere. But you might not be able to install so easily extensions.
Also a key value of SQLite is to be quite self contained and easy to build without strong dependency.
Finally, I'm not an expert of SQLite extensions, but I think that you will easily have a strong impact on performance using the extension for core type that you might use a lot in big tables.
(I think it's definitely useful as an extension but I can appreciate there's situations where a core feature is easier.)