is where the point where 28 October 2012 2:30 AM CEST and CET both get mapped to 1351387800. One suggested work-around I came accross doesn't work in my boundary case, confirming what the manual says: So how can we store our dates and times without being affected by this? The answer lies in designing your database (and application). Trusting your server's time zone settings and MySQL's time zone conversion abilities is a bad idea. Instead, use datetime fields and store UTC formatted values only. You can always get the current date and time in UTC via UTC_TIMESTAMP(), e.g.: Alternatively, you could store unix timestamps in unsigned int columns. But then you can not reliably use all those useful documented MySQL date and time functions, and, you would have to write your own date and time calculations using math in queries which can get messy. A disadvantage of storing all values in a datetime field is that you cannot make use anymore of the CURRENT_TIMESTAMP default value. But then again, if you need to store values outside the timestamp range or need 100% reliability, that might be one of your lesser concerns. Conclusion Use UTC formatted date and time values within MySQL and your application for reliability . Store all your date and time values in UTC format in a datetime column . Comments Tomas 07/02/2012 1:30am Eh, no discussion about using unix timestamps, which imho is superior to both options discussed here ... quite pointless