3 ms·

SQLites handling of dates is pretty kludgy. It stores them as strings, so to do something like extract just the year from a date, you have to do 'CAST(substr(g

SQLites handling of dates is pretty kludgy. It stores them as strings, so to do something like extract just the year from a date, you have to do 'CAST(substr(game_date,0,5) AS INTEGER).' Hackish and error prone.

MobiusHorizons 3y ago
It is a fairly low level abstraction, but one that does not require a verbose api. There is nothing error prone or hackish about what you have written, it will work for all inputs, it is just low level. You are just used to having other people write this code for you and give you a library. With newer versions of SQLite you could also write CAST(strftime(“%Y”, game_date)) as INTEGER Which is somewhat higher level and less easily mistyped
- SJC_Hacker 3y ago
  That's much better, thanks. In case I ever need to do years < 1000 or > 10000 :-) Still, having that all over a query looks ugly. SQL is can be unreadable enough as it is without all the joins/table renaming. I just want something more readable like EXTRACT(year from date), like you can in Postgres et al. Would also be nice if there was a native timestamp like there is in, pretty much every other database. I'm sensitive to "feature creep" but this doesn't seem like too big of an ask.
  - MobiusHorizons 3y ago
    I agree it's less obviously correct, but I bet you could add the extension to sqlite if you feel strongly about it. As an aside '%y' is documented to only work in sqlite for years >= 0000 and <= 9999, so it would behave exactly the same as the code you wrote. especially because you already didn't have to worry about years less than 1000 because the ISO8601 format used for serializing dates in sqlite normalizes them with leading zeros. for instance `select date(-50000000000, "unixepoch");` returns `0385-07-25` Interestingly %Y doesn't seem to handle negative dates either if you need to handle BC, so I guess that is one downside for both. This is one reason I sometimes prefer to use low level code even when it is less obviously correct with a cursory glance, because abstractions may not mean what you think they mean, or even worse, may be lying to you. At least with low level code I can reason about how it would behave under certain edge cases I might care about.
deleted 3y ago
[deleted]

MobiusHorizons 3y ago

It is a fairly low level abstraction, but one that does not require a verbose api. There is nothing error prone or hackish about what you have written, it will work for all inputs, it is just low level. You are just used to having other people write this code for you and give you a library. With newer versions of SQLite you could also write CAST(strftime(“%Y”, game_date)) as INTEGER Which is somewhat higher level and less easily mistyped

SJC_Hacker 3y ago
That's much better, thanks. In case I ever need to do years < 1000 or > 10000 :-) Still, having that all over a query looks ugly. SQL is can be unreadable enough as it is without all the joins/table renaming. I just want something more readable like EXTRACT(year from date), like you can in Postgres et al. Would also be nice if there was a native timestamp like there is in, pretty much every other database. I'm sensitive to "feature creep" but this doesn't seem like too big of an ask.
- MobiusHorizons 3y ago
  I agree it's less obviously correct, but I bet you could add the extension to sqlite if you feel strongly about it. As an aside '%y' is documented to only work in sqlite for years >= 0000 and <= 9999, so it would behave exactly the same as the code you wrote. especially because you already didn't have to worry about years less than 1000 because the ISO8601 format used for serializing dates in sqlite normalizes them with leading zeros. for instance `select date(-50000000000, "unixepoch");` returns `0385-07-25` Interestingly %Y doesn't seem to handle negative dates either if you need to handle BC, so I guess that is one downside for both. This is one reason I sometimes prefer to use low level code even when it is less obviously correct with a cursory glance, because abstractions may not mean what you think they mean, or even worse, may be lying to you. At least with low level code I can reason about how it would behave under certain edge cases I might care about.

deleted 3y ago

[deleted]