时区未检测 DST
我已将模拟器设置为该时区： org.apache.harmony.luni.internal.util.ZoneInfo["CET",mRawOffset=3600000,mUseDst=true]
这是布鲁塞尔时间，那里有 DST，所以我们是 GMT+02：夏季为 GMT+0000，冬季为 GMT+01:00。
但是，以编程方式无法检测 1970 年 7 月的 DST，但它会检测 2011 年的 DST。 例如：
TimeZone tz = TimeZone.getDefault();
if(tz.inDaylightTime(new Date(15638400000))){ //This timestamp is 01/07/1970 00:00:00:00 GMT
System.out.println("daylight time in July 1970"); //Not printed, despite being clearly in summer.
}
if(tz.inDaylightTime(new Date())){ // Now, 28/06/2011
System.out.println("daylight time in June 2011"); //printed, thats OK
}
这段代码有什么问题？ 1970年没有夏令时？同样的事情也发生在偏移量上，根据 javadoc，偏移量包括 DST：
int off = tz.getOffset(15638400000); //This returns +01:00, wrong!!
int off2 = tz.getOffset(System.currentTimeMillis()); //returns +02:00, OK.
关于这种行为的一些想法？ 谢谢。
编辑： 我对这个时区做了一些测试，检测到第一个实行夏令时的夏季是在1977年。毕竟这个政策的实施总得有一个开始日期。然而，1977年对我来说似乎有点晚了（石油危机发生在1970年和1973年）。我还没有找到任何官方文件证实这一点。
I've the emulator set to this timezone:org.apache.harmony.luni.internal.util.ZoneInfo["CET",mRawOffset=3600000,mUseDst=true]
This is Brussels time, where there is DST, so we are GMT+02:00 in summer and GMT+01:00 in winter.
However, programmatically there's no way to detect DST in July 1970, but it detects it for 2011. For instance:
TimeZone tz = TimeZone.getDefault();
if(tz.inDaylightTime(new Date(15638400000))){ //This timestamp is 01/07/1970 00:00:00:00 GMT
System.out.println("daylight time in July 1970"); //Not printed, despite being clearly in summer.
}
if(tz.inDaylightTime(new Date())){ // Now, 28/06/2011
System.out.println("daylight time in June 2011"); //printed, thats OK
}
What's wrong with this code? There was no DST in 1970? The same thing happens with the offset, which according to javadoc, includes DST:
int off = tz.getOffset(15638400000); //This returns +01:00, wrong!!
int off2 = tz.getOffset(System.currentTimeMillis()); //returns +02:00, OK.
Some ideas about this behavior?
Thanks.
EDIT:
I've made some tests for this timezone, and the first summer with DST is detected in 1977. After all, there has to be a starting date from which this policy was implemented. However, 1977 seems to me a bit late (oil crisis were in 1970 and 1973). I haven't found any official document confirming this yet.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
不了解比利时，但瑞典于 1980 年引入夏令时，因此比利时 1970 年没有夏令时可能是正确的。
但是，如果真正了解 1970 年 DST 对您的应用程序非常重要，那么您可能需要深入研究 java.util.Date 类的源代码或与
的结果进行比较>java.util.GregorianCalendar。Don't know about Belgium, but in Sweden DST was introduced 1980, so it might be correct that there was no DST for Belgium in 1970.
But if it is of big importance for your application to really know about DST in 1970 then you might need to dig into the source code of the
java.util.Dateclass or compare with result of thejava.util.GregorianCalendar.在真实设备（HTC Magic，操作系统 1.6）上进行测试，即使在 1970 年，它也能检测到布鲁塞尔/CEST 的 DST。因此，这是模拟器和真实设备之间不同行为的另一个示例。
我将在更新的设备上再次测试它，看看跨操作系统版本是否存在不同的 TZ 数据库。
更新
在 Samsung Galaxy Tab (OS 2.2) 上进行测试，行为与 HTC 相同。
Tested on a real device (HTC Magic, OS 1.6), it detects DST for Brussels/CEST even in 1970. So this is another example of different behaviour between emulator and real devices.
I'm going to test it again on a more recent device, to see if it there are different TZ databases across OS versions.
UPDATE
Tested on Samsung Galaxy Tab (OS 2.2), same behaviour than HTC.