1. Message timestamps are stored in databases as single numbers. More information about the most popular format of storing timestamps can be found here: https://en.wikipedia.org/wiki/Unix_time. Recovered data are often already partially rewritten, and if one of the rewritten items is the timestamp number, then after converting it to a readable time format you basically end up with a random date that falls into the constraints of a given timestamp system used.
   

2. Recovered data is never 100% reliable. However the probability of date being shifted only a little is very low. This is due to the way data are stored internally - small changes in data usually result in big changes in timestamps and it is rather hard to edit just least significant bits of the binary number that represents the timestamp. You can usually tell if the recovered item is corrupted or not. Look for indicators such as an unreadable or scrambled message body or other anomalies.
   

Data from one message are usually stored sequentially in the database and if some deleted entry is about to be rewritten and still remain recoverable then only the trailing part of the entry can be rewritten. Timestamps are usually stored in the front part of an entry, and therefore if they become corrupted so does everything else that follows them.