• 1 Post
  • 241 Comments
Joined 1 year ago
cake
Cake day: June 12th, 2023

help-circle














  • 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