gpt4 book ai didi

java - jdk8 日期转换中的错误?

转载 作者:塔克拉玛干 更新时间:2023-11-03 05:16:29 26 4
gpt4 key购买 nike

我正在为 java.util.Datejava.time.LocalDateTime 之间的 java-8 转换编写一些测试代码,发现异常似乎发生在 < strong>小时后从正常时间到夏令时的过渡,当年份为 2038 年或更高时。

我只是想知道这是不是jdk8的bug,还是我哪里做错了?

注意:我在 Windows-7,64 位 jdk,所以应该不会受到 2038-unix bug 的影响,它会有一个效果更差。

这是我的演示代码:

package conversiontest;

import java.text.SimpleDateFormat;
import java.time.LocalDate;
import java.time.LocalDateTime;
import java.time.LocalTime;
import java.time.ZoneId;

public class ConversionTest {

public static void main(String[] args) {
new ConversionTest().testDateConversion();
}

// Method under test:
public java.util.Date toJavaUtilDate(LocalDateTime localDateTime) {
return java.util.Date.from(localDateTime.atZone(ZoneId.systemDefault()).toInstant());
}

// Test-code:
public void testDateConversion() {
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
LocalDate localDate = LocalDate.of(2016, 1, 1);
LocalTime localTime = LocalTime.of(3, 22, 22); // 03:22:22
while (!localDate.toString().startsWith("2045-")) {
LocalDateTime localDateTime = LocalDateTime.of(localDate, localTime);
java.util.Date date = toJavaUtilDate(localDateTime);
String sLocalDateTime = localDateTime.toString().replace("T", " ");
String sJavaUtilDate = sdf.format(date);
if (!sLocalDateTime.equals(sJavaUtilDate)) {
System.out.println(String.format("FAILURE: '%s' != '%s'", sLocalDateTime, sJavaUtilDate));
}
localDate = localDate.plusDays(1);
}
}

}

输出:

FAILURE: '2038-03-28 03:22:22' != '2038-03-28 02:22:22'
FAILURE: '2039-03-27 03:22:22' != '2039-03-27 02:22:22'
FAILURE: '2040-03-25 03:22:22' != '2040-03-25 02:22:22'
FAILURE: '2041-03-31 03:22:22' != '2041-03-31 02:22:22'
FAILURE: '2042-03-30 03:22:22' != '2042-03-30 02:22:22'
FAILURE: '2043-03-29 03:22:22' != '2043-03-29 02:22:22'
FAILURE: '2044-03-27 03:22:22' != '2044-03-27 02:22:22'

从输出中可以看出,LocalDateTime(2038-03-28 03:22:22)转换为 java.util.Date(2038-03-28 02:22:22) 等。但是当年份低于 2038 时不会

有人对此有意见吗?

编辑:

我的 ZoneId.systemDefault() 给出:“欧洲/柏林”

C:\>java -version
java version "1.8.0_91"
Java(TM) SE Runtime Environment (build 1.8.0_91-b15)
Java HotSpot(TM) 64-Bit Server VM (build 25.91-b15, mixed mode)

C:\>javac -version
javac 1.8.0_91

最佳答案

不同的结果源于切换到夏令时的不匹配,夏令时从 2038 年的日期开始。您可以使用以下代码可视化差异:

// for reproducible results
System.setProperty("user.timezone", "Europe/Berlin");

LocalDate[] dates = {LocalDate.of(2037, 3, 29), LocalDate.of(2038, 3, 28)};
LocalTime[] time = { LocalTime.of(0, 59, 59), LocalTime.of(1, 00, 01),
LocalTime.of(1, 59, 59), LocalTime.of(2, 00, 01) };
for(LocalDate localDate : dates) {
for(LocalTime localTime1 : time) {
ZonedDateTime zoned = LocalDateTime.of(localDate, localTime1)
.atZone(ZoneId.of("UTC"))
.withZoneSameInstant(ZoneId.systemDefault());
System.out.println(zoned);
System.out.println(new java.util.Date(zoned.toEpochSecond()*1000));
}
System.out.println();
}

将打印:

2037-03-29T01:59:59+01:00[Europe/Berlin]
Sun Mar 29 01:59:59 CET 2037
2037-03-29T03:00:01+02:00[Europe/Berlin]
Sun Mar 29 03:00:01 CEST 2037
2037-03-29T03:59:59+02:00[Europe/Berlin]
Sun Mar 29 03:59:59 CEST 2037
2037-03-29T04:00:01+02:00[Europe/Berlin]
Sun Mar 29 04:00:01 CEST 2037

2038-03-28T01:59:59+01:00[Europe/Berlin]
Sun Mar 28 01:59:59 CET 2038
2038-03-28T03:00:01+02:00[Europe/Berlin]
Sun Mar 28 02:00:01 CET 2038
2038-03-28T03:59:59+02:00[Europe/Berlin]
Sun Mar 28 02:59:59 CET 2038
2038-03-28T04:00:01+02:00[Europe/Berlin]
Sun Mar 28 04:00:01 CEST 2038

正如我们所见,两种实现都同意在 2037 年切换到夏令时的时刻,而 java.util.* 实现在 2038 年一小时后切换。

这种行为变化源于 table of hardcoded transition times in sun.util.calendar.ZoneInfo它有一个有限的大小。正如我们所见at this point ,代码根据方法 getTransitionIndex 返回的索引进行分支。如果索引等于或大于表长度,it falls over to using a SimpleTimeZone implementation .

我们可以验证是否发生了这种情况:

long l1 = LocalDateTime.of(LocalDate.of(2037, 3, 29), LocalTime.of(1, 00, 01))
.atZone(ZoneId.of("UTC")).toInstant().getEpochSecond()*1000;
long l2 = LocalDateTime.of(LocalDate.of(2038, 3, 28), LocalTime.of(1, 00, 01))
.atZone(ZoneId.of("UTC")).toInstant().getEpochSecond()*1000;

TimeZone zone=TimeZone.getTimeZone("Europe/Berlin");
Field table=zone.getClass().getDeclaredField("transitions");
table.setAccessible(true);
System.out.println("table length="+((long[])table.get(zone)).length);

Method getTransitionIndex = zone.getClass()
.getDeclaredMethod("getTransitionIndex", long.class, int.class);
getTransitionIndex.setAccessible(true);
final Integer UTC_TIME = 0;
int indexFor2037 = (Integer)getTransitionIndex.invoke(zone, l1, UTC_TIME);
System.out.println("index for 2037="+indexFor2037);
int indexFor2038 = (Integer)getTransitionIndex.invoke(zone, l2, UTC_TIME);
System.out.println("index for 2038="+indexFor2038);

在我的系统上打印:

table length=143
index for 2037=141
index for 2038=143

我不知道有任何改变 2038 年夏令时切换的计划,所以我认为 java.time 实现是正确的。同样明显的是,任何基于硬编码值的有限表的实现都有一个自然的限制......

关于java - jdk8 日期转换中的错误?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/37551019/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com