DateTime.ParseExact跨设备解析日期报未识别为DateTime异常

你写的ParseExact逻辑硬编码了唯一匹配格式dd/MM/yyyy，且指定了CultureInfo.InvariantCulture，理论上不受客户端本地区域设置影响。同域部分机器抛出格式不识别异常，本质是部分环境下从SQL查询返回的实际日期字符串和你预设的格式不一致：比如不同SQL实例的语言/区域配置不同，可能返回MM/dd/yyyy、yyyy-MM-dd等其他格式的字符串，甚至带多余空格、特殊字符，ParseExact要求字符串和格式100%匹配，只要有偏差就会抛错。

.NET内置的DateTime.Parse和DateTime.TryParse方法原生支持传入区域文化编码，会自动加载对应文化下所有合法的日期格式规则做匹配，不需要手动枚举格式串。

基础用法示例 #

using System.Globalization;

// 传入目标区域文化编码，例如en-GB对应英式日期（日/月/年）、en-US对应美式日期（月/日/年）、zh-CN对应中文简体日期格式
string cultureCode = "en-GB";
CultureInfo targetCulture = CultureInfo.GetCultureInfo(cultureCode);
string dateStr = "21/07/2022"; // 从SQL查询得到的日期字符串

// 写法1：直接解析，格式不合法时会抛出异常
DateTime add_date = DateTime.Parse(dateStr, targetCulture);

// 写法2：推荐使用TryParse做容错处理，解析失败不会抛异常，通过返回值判断结果
if (DateTime.TryParse(dateStr, targetCulture, DateTimeStyles.None, out DateTime parsedDate))
{
    add_date = parsedDate;
    // 后续业务逻辑
}
else
{
    // 解析失败的处理逻辑：打日志、返回参数错误等
}

多格式兼容方案 #

如果你的业务场景需要兼容多种区域的日期格式，可以用DateTime.TryParseExact传入允许的格式数组，只要字符串匹配数组中任意一个格式就能解析成功：

string[] allowedFormats = new[] { "dd/MM/yyyy", "MM/dd/yyyy", "yyyy-MM-dd", "yyyy/MM/dd" };
if (DateTime.TryParseExact(dateStr, allowedFormats, CultureInfo.InvariantCulture, DateTimeStyles.AdjustToUniversal, out parsedDate))
{
    // 解析成功逻辑
}

从SQL读取日期类数据时，不要先转成字符串再做二次解析，直接用DateTime类型接收结果从根源规避格式问题：比如用SqlDataReader读取时直接调用GetDateTime(列索引)方法取值，用EF等ORM框架时也会自动把数据库的日期类型映射为C#的DateTime，完全不需要手动处理字符串格式。

如果因为特殊原因必须取字符串，建议在SQL查询时用CONVERT/FORMAT函数强制指定统一的日期输出格式，保证所有环境返回的字符串格式一致，再配合ParseExact解析就不会出现部分机器运行失败的问题。

内容的提问来源于stack exchange，提问作者user16242098