fiah

they aren't, except perhaps as a counterexample of some dubious sort

for what, Bluetooth?

which adds latency btw, no bueno

Or the no extra pay part.

oh yeah forgot about the title, that shit will NOT fly in europe at least

nah, a lot of people are miserable at their jobs all over the world. Just because there might be a decent social system that could tide them over should they lose that job doesn't mean they'll just quit

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

If only there was a summary of said article right here in the comment section, not even a click away

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

yeah well HP, fuck you too

lower visual noise of modern movies and series also helps a lot