никогда не зависит от конечной среды, а также от конфигурации установок для таких проблем. лучший способ быть на 100% уверенным в правильной глобализации (а также в локализации) - это поставить все проверки в самом коде. когда я знаю, что мое приложение будет использоваться в разных локалях, я явно получаю / устанавливаю текущую информацию о культуре через код. Кроме того, почти каждый метод синтаксического анализа для распространенных типов (таких как числа, дата и т. д.) имеет перегрузку, которая позволяет указывать информацию о культуре, которая будет использоваться при анализе специфичных для культуры данных. вы это гарантируете?
И последнее, но не менее важное: убедитесь, что ваш db-сервер ХОРОШО, КАК ваши sps правильно настроены и закодированы для ввода данных в разных локалях. например, у сервера sql есть много опций (включая стандарты ISO) для разбора / сохранения даты и времени. SQL Server 2008 предлагает вам гораздо проще и лучше варианты для той же цели
также, золотое правило с датой и временем - ВСЕГДА СОХРАНИТЬ ИХ в UTC, но отображать их в зависимости от текущего формата часового пояса / локали. одна очень распространенная ошибка, которую делают программисты, это НЕ сохранять информацию о дате и времени в формате UTC / GMT в БД. например: вместо сохранения DateTime.UTCNow они сохраняют DateTime.Now. Я видел дни, если не недели, потраченные на попытки выяснить такие ошибки / проблемы, когда приложение имеет дело с несколькими культурами / локалями / часовыми поясами. и то же самое, имея дело с числами. например: цена товара на сайте электронной торговли, который занимается продажами в разных странах и валютах