MySQL DATE/DATETIME fields do not store any timezone information, so it's usually regarded best to set your application's timezone to UTC, store datetime information as UTC and then adjust timezones on retrieval.

Storing DATE data sounds like just an awful idea if you're working with timezones. There's no information about whether it's 2am or noon, so there's no way to know if subtracting 5 hours will change the date or not.

I have a blog post here about how to manage this:

http://andrew.cool/blog/49/Easy-timezones-in-Laravel-with-Carbon

Basically override the Eloquent asDateTime function to apply a timezone offset. That way everything is stored in UTC but displayed in the current user's timezone. There is one caveat which is that when setting any timestamp you must set it to a Carbon instance and not a string.

Dates (vs. Datetimes) should not have a timezone at all. People celebrate Christmas on December 25th. It's not "December 25th at 12:00 am UTC." People in Chicago don't celebrate Christmas on December 24th at 7 pm. It's on that date no matter what timezone you're in. If you do have something that is taking place "at 12:00 am" in a specific timezone, then that's not a date, it's a Datetime, and you're just confused that it's a date because it takes place at midnight.