When you think about it storing a date with 6 bytes would take more space than using Unix time which would give both time and date in four bytes. Y2K38 is the real problem. Y2K was a problem with software written by poor devs that were trying to save disk space by actually using more disk space than needed.
This comes to mind:
You don’t store dates as Unix time. Unix timestamps indicate a specific point in time. Dates are not a specific point in time.
You also don’t store dates in a string that you’ll have to parse later. I’ve had to deal with MM-DD-YYYY vs. DD-MM-YYYY problems more times than I can count.
And you understand that you could have a date in unix time and leave the time to be midnight, right? You’d end up with an integer that you could sort without having to parse every goddamn string first.
And for God’s sake if you insist on using strings for dates at the very least go with something like YYYY-MM-DD. Someone else may someday have to deal with your shit code, at the very least make the strings sortable FFS.
This comes to mind:
You don’t store dates as Unix time. Unix timestamps indicate a specific point in time. Dates are not a specific point in time.
You also don’t store dates in a string that you’ll have to parse later. I’ve had to deal with MM-DD-YYYY vs. DD-MM-YYYY problems more times than I can count.
And you understand that you could have a date in unix time and leave the time to be midnight, right? You’d end up with an integer that you could sort without having to parse every goddamn string first.
And for God’s sake if you insist on using strings for dates at the very least go with something like YYYY-MM-DD. Someone else may someday have to deal with your shit code, at the very least make the strings sortable FFS.