Хранение DateTimes в UTC, безусловно, лучшая практика в моей книге.Преобразование существующих данных может потребовать значительных усилий, но в долгосрочной перспективе это будет стоить того, если у вас уже есть несколько пользователей в разных часовых поясах (сегодня два, но скоро это может быть три, четыре....) Это также поможет избежать проблем, связанных с такими вещами, как переход на летнее время, особенно если группы находятся в регионах, где начало и конец перехода на летнее время различны, как в случае между США и Великобританией.(Мне приходится иметь дело с этими проблемами DateTime в моей системе).
Я бы не стал полагаться на автоматическое определение часового пояса пользователя при вводе данных в ваш пользовательский интерфейс.Первое, что я хотел бы сделать, это связать пользователей в базе данных со свойством часового пояса.Не похоже, что ваши пользователи сильно меняют свои часовые пояса, если вообще когда-либо.
Не должно быть слишком сложно связать местоположения ни с пользователями, ни с группами пользователей, если вы этого еще не сделали.Просто добавьте информацию о часовом поясе вместе с их местоположением и используйте ее в своем коде при создании объекта DateTime из входных данных вашего.Это означает еще один фрагмент данных, которым кто-то должен будет управлять, но это будет менее хлопотно, чем попытка автоматического определения часового пояса с помощью кода.
Будет очень легко пропустить конверсии теперь, когда вы 'добавляем новый часовой пояс.Я бы порекомендовал убедиться, что вся ваша логика DateTime централизована (методы расширения или вспомогательный класс, в зависимости от версии вашей платформы).Храните все свои преобразования и форматирование строк в одном месте и убедитесь, что весь ваш код ссылается на него.
Удачи, и напишите множество юнит-тестов вокруг ваших преобразований.