Storing time information: Timezone required?

Whichever way you do it, it will fail in different ways depending on what is changing.

1. If you store timestamps in the according timezone as 2013-12-29 12:34:56 America/New_York, this will fail if, say, the Bronx suddenly starts their own timezone America/New_York_Bronx with a different offset and your event happened to be in the Bronx.

   Decide how likely this is and how bad a failure would be.

2. If you store timestamps in UTC and the timezone in which the event is happening is redefining their offset (e.g. shifting DST dates around, or entirely shifting to a different offset), the event time may differ from the actual wall clock time at that location. If you store 2013-12-29 12:34:56 UTC for an event at 13:34:56 in Berlin, Germany, and Berlin shifts their DST around, 2013-12-29 12:34:56 UTC may now correspond to 14:34:56 Berlin local time, while the event is still actually happening at 13:34 local time.

   Decide how likely this is and how bad a failure would be.

3. If you store the UTC timestamp and link it to a physical location which you then link to a timezone, you can counteract both problems. But for this you'll have to store the precise physical location, not just "New York", otherwise you just have case 1. with one more intermediate step. If you do store the precise physical location and have a precise way to resolve this location to a timezone and you keep your timezone database up to date, you can handle pretty much all change scenarios.

   Decide how practical this is and how much this extra precision is worth to you.

Scheduling future time is inherently hard, because you don't know what changes are coming in the future. It is a completely different beast than recording past time.

For past time events, all you really need is the local date and time, and the offset from UTC (many platforms call this a "DateTimeOffset").

But for future events, you don't necessarily know what the offset will be. You can guess what it is based upon your current knowledge of the time zone information, but that information is subject to change. In reality, it changes many times per year as governments of the world change their mind about daylight saving time and other situations.

Because you can't determine the offset reliably, you also cannot determine the exact UTC timestamp. So it's important that you hold on to the original local time. If you're going to calculate a UTC timestamp, you should also recalculate that any time you update your time zone data.

I've already written about this multiple times, (here, here and here). I suggest you read those posts.

Now you brought up one point that I hadn't touched on before, otherwise I'd have marked your question as a duplicate. That is - what if the location of the event moves into a new time zone entirely because the time zone boundaries have changed?

I agree with Deceze, that you need to think about how likely this scenario is and how bad a failure would be. In my opinion, it's probably not worth investing a lot of time to. If you have an event scheduled in the future and that location breaks off into a new time zone, you could always go back and edit the event. You need to ask yourself how much detail your app is expected to know about the time zone changes. Most scheduling systems I've worked with don't handle this aspect.

If it is indeed something that you want to handle, then you will need more than just the city. You should store latitude and longitude coordinates for the location. Then you can use one of these methods to resolve the time zone from those coordinates. But also note that you would want to make sure the source of the time zone boundaries was as up to date as possible.

Also note that the IANA Time Zone database that is the original source for the time zone data, does not keep boundary data at all! Most of the boundary data comes from independent sources, such as Eric Muller's shapefiles, which as of today is aligned with the 2013b data of the IANA database (which is at 2013i), so there have been at least 7 updates to the time zone data that either didn't change any boundaries, or the changes were not tracked.

When we were migrating our project from UK hosting to US machines, some of the data that was stored as DATETIME was problematic when we had to display data to clients. We had to chage server configuration for time being but it turned keeping dates as strings or date timestamp in db having them dependent from server configuration is not good idea. since then we do use unix timestamps for any dates in the system and we get rid of problem with timezones once for all. Clients decide to use timezone whatever they want to see. It's much easier to calculate time differences, filter data and so on.

The only problem is to make sure entered data into system it's correctly converted to unix timestamp. That means, user who enters the data should have (in your case) event's timezone when date is converted to timezone, otherwise user will need to calculate timezone on his own.