|
|
|
|
|
by petcat
11 days ago
|
|
Well for one we should probably validate that the number is smaller than the total life of the physical universe. SQLite will gladly store a u64::MAX as a "unix timestamp" despite it being about 300x larger than the number of seconds that the universe and everything in it has existed. Try reading that back in any application date/time code and your app probably crashes immediately. |
|
SQLite does not support unsigned integers.
> Try reading that back in any application date/time code and your app probably crashes immediately.
Postgres will happily ingest and produce dates in the 280th millenium, which will also crash your application if its datetime type can’t handle that shrug.
You can add a check constraint that your field passes through SQLite’s datetime functions and it’ll be clamped between the years 0 and 9999. Or you can put in your own limits matching your application layer, or your application’s business logic. That’s what check constrains are for (amongst other things).