除了"在操作系统中修改时区信息,然后重启.NET应用程序,使其生效"之外。如何在不修改操作系统时区的前提下,修改.NET中的默认时区呢?
这是一位 同学兼同事 于5月21日在技术群里问的问题,我当时简单地研究了一下,就写出来了。
现在写文章分享给大家,虽然我觉得这种需求非常小众,几乎不会有人用到。
正文
正常手段下,.NET是不允许开发者修改默认时区的,它没有公开这样的API。
在 .NET 中,管理时区的类型叫 TimeZoneInfo
,它位于 System
命名空间下,由 System.Private.CoreLib.dll
提供。
使用 ILSpy
反编译 System.Private.CoreLib.dll
,找到 TimeZoneInfo
类型,我们可以看到 TimeZoneInfo.Local
指向一个私有字段 s_cachedData
的成员属性 Local
,该字段类型是一个属于 TimeZoneInfo
的私有嵌套类型 CachedData
。
当首次访问 CachedData.Local
时,它会先检查 _localTimeZone
私有字段是否有值。如果没有值,则调用 CreateLocal
方法从操作系统获取时区信息并且赋值。
看到了这里,我脑海里就浮现了两种方案:
- 使用
hook
技术挟持并修改win32 api
返回的时区信息。 - 使用
reflection
技术反射并且修改时区信息。
方案1的优点是稳定,但可能会被杀毒软件报毒。
方案2的优点是不会报毒,但可能不稳定。
为什么说方案2不稳定呢?因为 s_cachedData 私有字段值有可能在某个时候被重置。
现在我们来看看方案2的实现:
csharp
public static bool TrySetLocalTimeZoneInfo(TimeZoneInfo timeZoneInfo)
{
Type timeZoneInfoType = typeof(TimeZoneInfo);
// 获取TimeZoneInfo类型的私有静态字段成员信息s_cachedData
FieldInfo cachedDataFieldInfo = timeZoneInfoType.GetField("s_cachedData", BindingFlags.NonPublic | BindingFlags.Static);
if (cachedDataFieldInfo == null)
{
return false;
}
// 获取TimeZoneInfo类型的私有嵌套类型CachedData
Type cachedDataType = timeZoneInfoType.GetNestedType("CachedData", BindingFlags.NonPublic);
if (cachedDataType == null)
{
return false;
}
// 获取CachedData类型的私有字段成员信息_localTimeZone
FieldInfo localTimeZoneFieldInfo = cachedDataType.GetField("_localTimeZone", BindingFlags.NonPublic | BindingFlags.Instance);
if (localTimeZoneFieldInfo == null)
{
return false;
}
// 获取TimeZoneInfo类型的私有静态字段s_cachedData值
object cachedData = cachedDataFieldInfo.GetValue(null);
if (cachedData == null)
{
return false;
}
// 设置私有字段的值
localTimeZoneFieldInfo.SetValue(cachedData, timeZoneInfo);
return true;
}
PS: 该方法代码实际测试在 .NET Core 3.1
, .NET 5.0
, .NET 6.0
, .NET 7.0
, .NET 8.0
都可以正常工作。
用法:
csharp
void Main()
{
// 设置前
Console.WriteLine(TimeZoneInfo.Local);
// 修改为 GMT 时区
TimeZoneInfo hkTimeZoneInfo = TimeZoneInfo.FindSystemTimeZoneById("GMT Standard Time");
bool setResult = TrySetLocalTimeZoneInfo(hkTimeZoneInfo);
// 设置后
Console.WriteLine(TimeZoneInfo.Local);
}
注意:这种方案需要严谨测试,反复验证。
因为是篡改.NET内部私有变量,不知道是否会引起其它后果。
比如.NET内部其它API没有使用 TimeZoneInfo.Local
,而是自己在其它地方又缓存了一套 TimeZoneInfo
,那就GG了。
又比如,需要检查整个 .NET Runtime
和其它第三方组件,是否有调用 TimeZoneInfo.ClearCachedData
静态方法 或者 调用 CultureInfo.ClearCachedData
对象方法。