The precision — or lack thereof — of time
Exactly how long is a month? 30 days? 31? Likewise you never want to try and deal with a time without a date, because then you can’t handle daylight savings or any other timezone changes.
.. Where things really fall apart is when you try and sequence events in a database, because the data from a transaction won’t be visible to other transactions until it commits. If transaction A runs from 12:00 to 12:03 and transaction B runs from 12:01 to 12:02, which transaction happened first? You might want to say A because it started first. But A can potentially see data from B after B commits. Conversely, you could say B happened first because it commits first, but clearly some events in transaction A happened before B even started.
.. A simple example is the “midnight problem.” Say you’re tracking visitors to your website, and you want to know how many people visit per day. Someone that first hits your site at 11:59PM and stays for a while will end up counted twice if you’re not careful. Once at 11:59 and then a second time after midnight. Technically all those visitors did visit on both days; but you may not have wanted to actually double-count them.
.. Another strong variation is to actually create a cryptographic hash for each record that includes the hash of the previous record. That makes it impossible for old data to be erased or changed without detecting it.