also it's not a trivial task to engineer for swapable EV batteries, doing so comes with a whole host of disadvantages / compromises that don't make sense for most (I guess) consumers right now. It's not very different from the phone battery issue, except on a huge scale and with much more severe consequences if things go wrong
I think part of it is that some of the Lemmy crowd came over because they were banned on reddit for being hyper-disagreeable, rude, violent lil bastards
where was the victory parade on the 4th day of this special operation?
edit: lol I just got banned from the lemmy.ml world news for suggesting that it's way past a hexbear's bed time. I guess I should've known those mods are tankies
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
why not? assuming you're saving them all in UTC they should be perfectly sortable and comparable (before, equal, after) as strings, even with varying amounts of precision when you compare substrings. You can't really do math with them of course, but that's what I meant about how DBs interpret dates and time: if you use it do to math and then you also use your application's date library to do math, you'll likely run into situations where the two come to different answers due to timezone settings, environments, DB drivers and the like. Of course if I could rely on the DB to do the math exactly the way I'd expect it to, then having that ability is awesome, however that requires more knowledge about databases and their environments than I currently have
Personally, I would probably just store them as text, because I'm objectively a terrible programmer.
I don't know man, I'd far prefer storing a string and have whatever date library I'm using figure it out than have to deal with whatever the database thinks about dates and timestamps
they aren't, except perhaps as a counterexample of some dubious sort