[MarcusBrutus]

In your database always store time as seconds since the Epoch (or milliseconds since the Epoch if you need more precision). Forget about SQL date/time types, they are useless. Then convert to "civilian format" only in the presentation layer. You can't go wrong with that.

Seconds since the Epoch is unambiguous, eschews time zones, daylight savings time and other man-made concepts (it makes sense to Martians too). Plus it only requires an INTEGER type in the database which every RDBMS provides (so is migration safe). You also create demand for your future colleagues (or future self) around 2038. Or you can use BIGINT if that bothers you.

[TheCoelacanth]

Seconds since Epoch is always unambiguous, but you can't always unambiguously convert a time to seconds since Epoch. If I set my alarm clock to 7 AM while I am in EST and you save that as 11 AM UTC, then I travel to somewhere that is in CST that 7 AM is now 12 PM UTC and the time you saved is now wrong.

[rolux]

As others have pointed out, you can go wrong with that. If you don't store the local time and timezone, then your integer becomes meaningless whenever the DST rules change, as you can no longer tell if your conversion back to local time corresponds to the initial conversion from local time.