当前位置: 首页 > 知识库问答 >
问题:

Windows 7时区规则中是否存在漏洞[重复]

臧俊杰
2023-03-14

英国夏令时每年将时钟在3月向前调整,10月向后调整。在1968年至1971年期间,英国将英国夏令时作为一种永久选择进行了试验,因此时钟在1968年3月向前调整了1小时,直到1971年10月才恢复。

我正在用Javascript创建日期,将它们序列化为JSON并发布到WebApi。

目前使用windows 7作为开发环境,windows不承认这段时间为BST。例如,1970年1月1日应该是夏令时

new System.DateTime(1970, 01, 01, 00, 00, 00).IsDaylightSavingTime();

返回false。

而且

System.TimeZone.CurrentTimeZone.GetDaylightChanges(1970)
{System.Globalization.DaylightTime}
    Delta: {01:00:00}
    End: {25/10/1970 02:00:00}
    Start: {29/03/1970 01:00:00}

1970年应该有一个覆盖全年的规则,因为全年是英国夏令时。

是否有修补程序来纠正Windows中的缺陷?

共有3个答案

伯鸿达
2023-03-14

正如评论中所述,您所展示的代码使用的是您正在运行该代码的计算机上的当前时区。这可能是英国,但这不是一个好主意。以下代码考虑了上述注释:

var tzi = TimeZoneInfo.FindSystemTimeZoneById("GMT Standard Time");
var dt = new DateTime(1970, 1, 2, 0, 0, 0, DateTimeKind.Utc);

var isDlt = tzi.IsDaylightSavingTime(dt);

虽然这也返回false,但您声明的错误确实存在。我非常怀疑是否有补丁,但如果您如此倾向,您可以很容易地编写一个扩展方法,使用IANA数据库来确定给定日期是否在夏令时。

您可能还想查看TimeZoneInfo的文档。GetAdjustmentRules-https://msdn.microsoft.com/en-us/library/system.timezoneinfo.getadjustmentrules(v=vs.110)。aspx

隆睿
2023-03-14

Windows在英国没有单独的时区。英国Windows使用的时区(“GMT标准时间”)与爱尔兰和葡萄牙共享。

这就是为什么只适用于英国的历史偏差没有得到反映。

即使在过去的200年里,各国的边界也发生了很大的变化,直到最近(仅仅几十年前),欧洲很小的地区都有自己的时区定义,而且变化频繁。Windows无法反映这种复杂的信息。如果你需要这些信息,你需要使用一个专用的数据库。

长孙雅志
2023-03-14

使现代化

毕竟有一个错误,或者更确切地说GMT Standard Time不包含英国特定的规则。1968年至1970年间,英国的偏移量改为1:00,并且没有夏令时。

真正的问题是,英国在这一时期的抵消是错误的:

var date= new DateTime(1970,1,1,0,0,0,DateTimeKind.Local);
var tzi = TimeZoneInfo.FindSystemTimeZoneById("GMT Standard Time");
var offset=tzi.GetUtcOffset(date);

offset00:00:00。哎呀!

对于1970-08-01,偏移量为01:00:00IsDaylightSavingTime()返回True。

PS:SQL服务器的AT TIME ZONE使用Windows时区名称。这可能是历史数据问题的更大来源。

起初的

没有虫子 当一整年只有一个补偿时,谈论夏令时是没有意义的。

IANA时区数据库显示1970-01-01没有使用DST。偏移量是1:00。使用NodaTime:

var london = DateTimeZoneProviders.Tzdb["Europe/London"];

// Time zone conversions
var localDate = new LocalDateTime(1970, 1, 1, 0, 0, 00);
var before = london.AtStrictly(localDate);

Console.WriteLine($"{before} {before.IsDaylightSavingTime()} {before.Offset}");

这将返回:

1970-01-01T00:00:00 Europe/London (+01) DST:False +01

1971-11-01年的结果是:

1971-11-01T00:00:00 Europe/London (+00) DST:False +00

此时偏移量从1:00更改为00:00,DST规则重新引入。

结果对夏季约会更有趣。

1971-07-30返回:

1971-07-30T00:00:00 Europe/London (+01) DST:False +01

这是正确的——当时没有DST规则生效。偏移量固定为1。

1972-07-30返回:

1972-07-30T00:00:00 Europe/London (+01) DST:True +01

偏移量是相同的,因为DST规则在该日期生效。

 类似资料:
  • 正如我们在新闻中看到的,针对流行的库报告了一个新的零日漏洞,该漏洞允许攻击者远程执行代码。在我们的应用程序中,我们仍然使用以下依赖项。 是否仅针对报告该问题?或适用于版本是否也是?是否有测试该漏洞的示例代码?

  • 我最近在Log4J中读到了关于0天问题的文章。我使用了一些应用程序,这些应用程序是用。NET的日志库,它使用基于Log4j的log4net日志库。 log4net是否存在与log4j的CVE-2021-44228漏洞类似的安全漏洞?

  • Joe Albahari有一个很棒的多线程系列,这是必读的,任何做C#多线程的人都应该熟记于心。 然而,在第4部分中,他提到了volatile的问题: 请注意,应用volatile并不能阻止先写后读的交换,这可能会产生脑筋急转弯。Joe Duffy用下面的例子很好地说明了这个问题:如果Test1和Test2同时在不同的线程上运行,那么a和b的值都可能为0(尽管在x和y上都使用volatile) 然

  • 是否存在一种“内部安全应用程序”场景,其中由于早期的Log4J版本,软件比没有它时更容易受到攻击? 我在下面概述了这个问题的一些细节。 我正在做一些工作来减轻最近Log4J漏洞的风险。我知道有一些方法涉及从组织的所有计算机、服务器、远程桌面等中删除早期Log4J jar文件的所有痕迹,在完成之前,组织被视为“处于危险之中”。然而,我也想知道如此大规模的全面努力支出是否相称[编辑22-12月21日1

  • 关于已经在CVE-2021-44228发现的Log4j JNDI远程代码执行漏洞-(另见参考文献)-我想知道Log4j-v1.2是否也受到影响,但是我从源代码审查中得到的最接近的是JMS-Appender。 问题是,虽然互联网上的帖子表明Log4j 1.2也存在漏洞,但我找不到相关的源代码。 我是否遗漏了其他人已经确认的东西? Log4j 1.2在socket server类中似乎有一个漏洞,但我

  • 我使用的是带有Scala 2.12的Databricks群集版本7.3 LTS。这个版本确实使用Log4J。 官方文件说它使用Log4J版本。这是否意味着我没有这个漏洞?如果我这样做了,我可以在集群上手动修补它,还是需要将集群升级到下一个LTS版本?