Learned this from a friend. The types are null, integer, real, text, and blob. My friend describes them thusly:
- Null stores nothing, but like, actively nothing, as opposed to the absence of a thing.
- Integer is a signed integer, up to 8 bytes.
- Real is always an 8-byte float.
- Text is an arbitrary-length UTF-8 or UTF-16.
- Blob is an arbitrary-length anything-else. But I hope you remembered what you put there. Because it sure isn’t gonna tell you. Oh, and it doesn’t have strong typing, so if you ask for it back as an integer, it’ll quite happily give you it back as an integer, especially if that doesn’t make sense!
But, you totally can? When you store all your dates as an ISO 8601 string (UTC, so with Z at the end), you can simply compare the strings themselves with no further complications, if the strings match, the dates match, if one string is less than the other, the date therein is before the other. Their lexical order is equal to their chronological order
I agree that it’s a massive and unnecessary overhead that you should definitely avoid if possible, but for anything where this overhead is negligible it’s a very viable and safe way of storing date and time
edit: I forgot, there’s also a format that’s output by functions like toUTCstring that’s totally different and doesn’t have any logical order, but I honestly forgot about that format because nobody in their right mind would use it