能否在C#中将EST、CET、PST等短时区字符串转换为TimeZoneInfo？

当然可以处理，但有个关键前提要先明确——这些时区缩写并不是全球标准化的，比如EST可能被多个地区用来指代不同的时区（虽然大部分情况下我们默认是美国东部标准时间，但严格来说存在歧义）。不过你不想硬编码庞大的映射表，确实有几种相对灵活的方案可以试试：

方案1：利用.NET内置的TimeZoneInfo遍历匹配 #

.NET本身没有直接解析这些缩写的API，但我们可以遍历系统中所有的时区信息，匹配它们的标准时间名称或夏令时名称里的缩写。这种方法不需要额外依赖，但要注意歧义问题。

举个示例代码：

public static TimeZoneInfo? GetTimeZoneByAbbreviation(string abbreviation)
{
    // 遍历系统中所有可用时区
    foreach (var timeZone in TimeZoneInfo.GetSystemTimeZones())
    {
        // 检查标准时间名称是否包含目标缩写（不区分大小写）
        if (timeZone.StandardName.IndexOf(abbreviation, StringComparison.OrdinalIgnoreCase) >= 0)
        {
            return timeZone;
        }
        // 再检查夏令时名称
        if (timeZone.DaylightName.IndexOf(abbreviation, StringComparison.OrdinalIgnoreCase) >= 0)
        {
            return timeZone;
        }
    }
    // 没有匹配到时区则返回null
    return null;
}

注意点： #

• 这种方法可能会匹配到多个时区（比如某些小众地区的时区也可能用类似缩写），如果你的业务场景有明确的地区范围，可以在遍历的时候额外过滤（比如只保留包含"America/"或"Europe/"前缀的时区ID）。
• 缩写的匹配是模糊匹配，比如如果输入"ST"，可能会匹配到所有包含"ST"的时区名称，所以最好确保输入的缩写是完整的（比如EST而非ES）。

方案2：使用NodaTime库（更可靠的时区处理） #

如果你的项目可以引入第三方库，NodaTime是处理时区问题的绝佳选择，它基于IANA时区数据库，对时区缩写的支持更完善，也能更好地处理歧义。

首先需要通过NuGet安装NodaTime包，然后可以这样实现：

using NodaTime;
using NodaTime.TimeZones;

public static DateTimeZone? GetDateTimeZoneByAbbreviation(string abbreviation, string regionCode = "US")
{
    var tzdbProvider = DateTimeZoneProviders.Tzdb;
    // 先过滤指定地区的时区，减少歧义（比如US代表美国地区）
    var targetZones = tzdbProvider.GetZoneIds().Where(id => id.StartsWith($"{regionCode}/"));
    
    foreach (var zoneId in targetZones)
    {
        var dateTimeZone = tzdbProvider[zoneId];
        // 获取当前时间对应的时区区间，检查区间名称是否匹配缩写
        var currentIntervals = dateTimeZone.GetZoneIntervals(Instant.FromDateTimeUtc(DateTime.UtcNow));
        foreach (var interval in currentIntervals)
        {
            if (interval.Name.Equals(abbreviation, StringComparison.OrdinalIgnoreCase))
            {
                return dateTimeZone;
            }
        }
    }
    return null;
}

优势： #

• 可以通过指定regionCode来缩小匹配范围，比如传入"EU"就能匹配欧洲的CET时区，避免歧义。
• NodaTime的时区数据更全面，更新也更及时，能覆盖更多边缘场景。

最后提醒 #

如果有可能的话，尽量让输入方提供完整的时区ID（比如"Eastern Standard Time"或"IANA标准的America/New_York"），这才是最可靠的方式，毕竟缩写的歧义问题很难完全避免。但如果只能拿到缩写，上面的两种方案可以帮你省去硬编码映射表的麻烦。

内容的提问来源于stack exchange，提问作者Cristian Florin Zlatea