Having the DateTimes stored in UTC is definitely a best practice in my book. It may be quite a bit of work to convert your existing data, but it's probably going to be worth it in the long term if you already have a few users in different time zones (today it's two, but soon it could be three, four....) It's also going to make it easier to avoid problems around things like daylight savings time conversions, especially if the groups are in regions where the start and end of daylight savings is different, which is the case between the US and UK (I have to deal with these DateTime issues in my system).
I would not rely on any automatic detection of a user's timezone when data is entered into your UI. The first thing I'd do is associate users in the database with a timezone property. It doesn't sound like your users are changing their timezones much, if ever.
It shouldn't be too difficult to associate locations with either users or groups of users if you're not already doing it. Just add the timezone information along with their location, and use that in your code when creating a DateTime object from the input from your. It means one more piece of data that someone will have to manage, but it's going to be less troublesome than trying to automatically detect the timezone through code.
It's going to be very easy to miss conversions now that you're adding a new time zone. I would recommend making sure all your DateTime logic is centralized (extension methods or a helper class, depending on your framework version). Keep all your conversions and string formatting in a single place and make sure all your code references it.
Good luck, and write lots of unit tests around your conversions.
