Doesn't Postgres' UUID type just do this for you anyway?
replyWhy would you store it as as str column and not the inbuilt type for this?
https://www.postgresql.org/docs/current/datatype-uuid.html
If you are using SQLite well I guess that doesn't work.
Small nit: uuid7 is 128 bits (16 bytes) by definition. So there’s no need to convert it to binary. It already is. Unless you’re working with a stringified version of the uuid7.
replyOh yes, I meant don’t store as an ID in its string format!
replyIt's just s dumb as storing dates as strings, but people still do it.
replyBut SQLite does not have a native datetime type so you have to use strings
replyYou can use an integer
replyHow do I know the time zone of an integer? Sure there are plenty of cases where one doesn't care, but there are also many cases where the original time zone is important.
replyThe integer is a UTC time so it can be sorted. If you need the time zone you store than in a smaller field.
replyother comment said it already, timezone information is not saved. Easiest is just to use a string.
replyBut also one of the recommended ways of doing it, as it has no native Datetime type.
reply> and you should always convert that to binary to optimize everything
replyI disagree. I tried this once. Now you need a client access layer to touch the DB in any context. All your console tools no longer work well or at all. If they show up in URLs you need to deoptimize them for transport.
You give up a lot of convenience for this optimization. You should be absolutely sure your design requires it before using it.