If someone gave that problem to me, I would probably do the following:
All the data in the system should be stored in one time zone (normally UTC), then only when the value needs to be printed to the output should time zone offset be applied.
The user sets an all day event, which would appear to the user as 00:00:00.000 - 23:59:59.999 in the user's local time. This means that finding scheduling conflicts is trivial, as opposed to having to check somehow if an event is marked as all day.
Now, as for storing it, if you have users in different time zones the best thing to do is to convert everything to UTC before storing in the database. Then when rendering a particular user's calendar, convert it to their local time for the purposes of display only.
When the user does anything date related, the backend should always be working on UTC, only ever taking into account the offset when it's time to print something to the user.
Doing it this way means you will very rarely have to worry about time zones, and checking conflicts is really simple. If a user on +6 hours looks at a user's schedule on -5 hours, the interface should ideally show the event over the time adjusted to the viewing user's time. This means an all day event in London would run from 5:00am - 4:59:59.999pm when viewed in a +5 time zone. It's no good to the person in a different time zone if his calendar shows the event over two whole days, or over one (incorrect) day as if he needs to call or be involved somehow, he may easily miss it.
Thanks to @Blrfl for linking to it, but many DBMS's have excellent support for time zone operations built in so you might not want to do what I suggested. As for displaying it, I would still recommend displaying it as overlapping days, especially if other user's events from various timezones will be displayed on the same calendar.