java 错误日期转正确日期_java – jdk8日期转换中的错误？

我正在为java.util.Date和java.time.LocalDateTime之间的java-8转换编写一些测试代码,发现异常似乎发生在从正常时间到夏季的转换后的一小时内,当年是2038年或更高.

我只是想知道这是jdk8中的错误,还是我做错了什么？

注意：我使用的是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年后一小时后切换.

我们可以验证这种情况发生了：

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,java-8,java-time,java-util-date

来源： https://codeday.me/bug/20190519/1135074.html