It just struck me that if you are only displaying event data for the purpose of visiting these events IRL, then you might as well store all times in local time. After all, if I live in Central Europe and are checking out events in New York for my vacation there, do I really need to know when they happen if I stayed at home?
If you on the hand rather (or also) are displaying event data for the purpose of watching events online / TV / radio, then you would indeed need to (also) convert times to the user's timezone.
Assuming an event is entered into the database by a person, and furthermore assuming that said person is aware of the event-local timezone, they could specify the timezone when creating the event. If this is an ok approach, you could easily list the possible timezones in a select box by using the event's target country's two letter ISO 3166-1 country code.
For example, assuming the event is taking place in england, using country code GB will list Europe/London as possible timezones.
$li = DateTimeZone::listIdentifiers(DateTimeZone::PER_COUNTRY, 'GB');
$out = "<select>\n";
foreach ($li as $tz)
{
$out .= "<option>$tz</option>\n";
}
$out .= '</select>';
printf('<pre>%s</pre>', htmlentities($out));
If you need to automate the timezone conversion process, you would need to create separate tables for timezones, countries and cities, where city also includes a timezone foreign key. An event would then store its location as ids relating to the city table, which in turn give you the timezone. And when storing an event, the location has to be known, which would enable a lookup for the timezone.