Windows与Linux下DateTime解析两位年份的差异问题

这问题我之前帮别人排查过，本质是跨平台下日期解析依赖系统区域设置导致的不一致，我给你拆解原因和解决办法：

Convert.ToDateTime在解析含两位年份的字符串时，会依赖当前系统的区域设置（CultureInfo）里的TwoDigitYearMax属性——这个属性决定了两位年份会被映射到哪个世纪：

• 你的Windows系统里，这个值可能被设置为2037（或更高），所以"37"会被解析成2037；
• 而Linux系统的默认区域设置中，TwoDigitYearMax大概率是2029（这是很多区域的默认阈值），所以"37"超过了29，就被映射到1937。

至于"20"能两边一致解析成2020，是因为不管2029还是2037的阈值，20都小于等于这个值，所以都被归到21世纪。

要解决跨平台一致性，核心是不要依赖系统默认的区域设置，显式指定解析规则，给你几个靠谱的方案：

方案1：使用精确格式解析（推荐） #

用DateTime.ParseExact或DateTime.TryParseExact，明确指定日期格式，同时自定义TwoDigitYearMax来统一两位年份的映射规则：

// 待解析的日期字符串
string dateString = "7/14/37 8:11:02 AM";
// 匹配字符串的格式模板
string format = "M/d/yy h:mm:ss tt";

// 创建对应格式的文化信息（这里用en-US适配MM/dd/yy格式）
var culture = new CultureInfo("en-US");
// 设置两位年份的最大映射年份，比如设为2099，00-99都会解析为2000-2099
culture.Calendar.TwoDigitYearMax = 2099;

// 执行解析
DateTime planExpDate = DateTime.ParseExact(dateString, format, culture);

这样不管在Windows还是Linux，都会把"37"解析成2037，完全一致。

方案2：从源头使用四位年份 #

如果可以控制输入的日期字符串，直接传入四位年份（比如"7/14/2037"），彻底避免两位年份的歧义，这是最省心的方式。

方案3：全局设置TwoDigitYearMax #

如果你的项目里很多地方都要解析两位年份，可以在程序启动时全局设置对应CultureInfo的规则：

var culture = CultureInfo.CurrentCulture.Clone() as CultureInfo;
culture.Calendar.TwoDigitYearMax = 2099;
CultureInfo.CurrentCulture = culture;
CultureInfo.CurrentUICulture = culture;

这样后续所有的日期解析都会遵循这个规则，但注意这会影响全局的文化设置，需要根据项目情况评估。

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