Don't do this in your database. Use your datetime types. Please. You might save some work with your timezone but you're not going to be able to use intervals etc in a smart way.
This would be even dumber with PostgreSQL, which has much more robust date/time functionality (being able to use the - operator with datetimes and intervals, for example) and completely sane timezone support.
The only true problem with storing unix time is leap seconds and relativistic effects, which can both be safely ignored for most time keeping usages.
Even just saying "24 hours from now" -- as your user would see it -- you'll sometimes get the wrong answer if you just add on 24 hours worth of seconds... suppose they have a DST shift tonight?
What if you need to know how many days remain from today to March 1st of this year? ...well, are we in a leap year?
Postgres datetime doesn't solve all of the problems that crop up, but it's certainly better than using unix time.
Same for working out how many days remain - you convert March 1st to a unix date, get an interval in seconds, and then convert that into a human readable format on display.
This isn't some revelation - unix time has been used successfully for decades now.
EDIT: Also, Postgresql uses a number very similar to unix time in the actual storage of the date - it just handles the pretty display for you. So you're arguing for using the same thing whether you say use a postgre datetime or a unix date number.
It's rather more than that, though I don't have the time to kill digging into it now.
And personally I mostly seem to end up doing more complicated date processing in code, not queries; but there everything needs to be a date immediately (not unix time or similar) for most purposes -- then I can use complicated libraries written by others to let me do "simple" things with dates, like rolling months.
Ah, also: > you convert March 1st to a unix date Then that's where the complicated logic goes. Basically, you need that somewhere, and it's non-trivial (leap year calc is the least of it).
My point isn't that unix dates aren't useful for storage, but that they aren't useful by themselves for calculation.
Postgresql and every other database that I'm aware of stores dates internally as a 4 or 8 bit number anyway, so you aren't saving anything by using an (hopefully) bigint instead of a datetime column.
Unsurprising, given how cavalier MySQL is with all the other data it "stores".