java - 从 java.sql.Timestamp 到 joda 的 LocalDate 的意外转换

标签 java calendar jodatime

我在将 Timestamp 对象转换为 joda 的 LocalTime 时遇到问题。

请看下面的例子:

public static void main(String[] args) {

    Timestamp t = Timestamp.valueOf("1111-11-11 00:00:00");
    System.out.println(t); //-- prints '1111-11-11 00:00:00.0'
    System.out.println(new LocalDate(t)); //-- prints '1111-11-17'

    Calendar calendar = Calendar.getInstance();
    calendar.setTime(t);
    System.out.println(LocalDate.fromCalendarFields(calendar)); //-- prints '1111-11-11'
}

我无法确定为什么“new LocalDate(t)”会导致“1111-11-17”。谁能帮我解决这个问题?

我在使用 joda-time-hibernate 填充我的 bean 类型为 LocalDate 的属性时注意到这个“问题”。

最佳答案

这确实与不同类型的日历有关。 java.sql.Timestamp,与 java.util.Date 一样,没有任何日历信息,因为它们仅以数字形式存储,即自 1970 年以来的毫秒数, 隐含的假设是在 1582 年 10 月 4 日和 10 月 15 日之间有一个跳跃,当时公历被正式采用,取代了旧的儒略历。因此,您不可能拥有表示 1582 年 10 月 7 日的日期(或时间戳)对象。如果您尝试创建这样的日期,您将自动在 10 天后结束。例如:

    Calendar c = Calendar.getInstance();
    c.setTimeZone(TimeZone.getTimeZone("UTC"));
    c.set(1582, Calendar.OCTOBER, 7, 0, 0, 0);
    c.set(Calendar.MILLISECOND, 0);
    d = c.getTime();
    System.out.println("Date: " + d);
    // Prints:
    // Date: Sun Oct 17 00:00:00 GMT 1582

换句话说,Date 对象具有隐含的 Julian+Gregorian 年表,可在这两者之间自动切换。

JodaTime 更聪明一些,它支持多种年表,包括持续的 Julian,proleptic Gregorian,Julian+Gregorian 的混合体,以及与 Gregorian 几乎相同的标准 ISO 年表。如果你阅读 the JavaDoc of the LocalDate.fromCalendarFields method ,你会看到它提到:

This factory method ignores the type of the calendar and always creates a LocalDate with ISO chronology.

混合的 Julian+Gregorian 年表表现得像隐式 Java 日期,在两种不同的日历之间自动切换。纯年表假设他们的日历系统永远在使用,例如,它假设从时间开始就使用公历。

让我们看看每个 Chronology 如何处理 1111-11-11 日期:

    Calendar c = Calendar.getInstance();
    c.setTimeZone(TimeZone.getTimeZone("UTC"));
    c.set(1111, Calendar.NOVEMBER, 11, 0, 0, 0);
    c.set(Calendar.MILLISECOND, 0);
    Date d = c.getTime();
    System.out.println("Date: " + d + " (" + d.getTime() + " milliseconds)");
    System.out.println("ISO: " + new DateTime(d, ISOChronology.getInstance(DateTimeZone.forID("UTC"))));
    System.out.println("Julian+Gregorian: " + new DateTime(d, GJChronology.getInstance(DateTimeZone.forID("UTC"))));
    System.out.println("Julian: " + new DateTime(d, JulianChronology.getInstance(DateTimeZone.forID("UTC"))));
    System.out.println("Gregorian: " + new DateTime(d, GregorianChronology.getInstance(DateTimeZone.forID("UTC"))));

结果为:

Date: Sat Nov 11 00:00:00 GMT 1111 (-27079747200000 milliseconds)
ISO: 1111-11-18T00:00:00.000Z
Julian+Gregorian: 1111-11-11T00:00:00.000Z
Julian: 1111-11-11T00:00:00.000Z
Gregorian: 1111-11-18T00:00:00.000Z

如您所见,两种现代年表(ISO 和公历)报告正确的日期如果它们从一开始就被使用,而使用儒略历的两个报告日期当时已知,尽管事后我们知道它与真正的春分日期相差 7 天。

让我们看看开关周围发生了什么:

    c.set(1582, Calendar.OCTOBER, 15, 0, 0, 0);
    d = c.getTime();
    System.out.println("Date: " + d + " (" + d.getTime() + " milliseconds)");
    System.out.println("ISO: " + new DateTime(d, ISOChronology.getInstance(DateTimeZone.forID("UTC"))));
    System.out.println("Julian+Gregorian: " + new DateTime(d, GJChronology.getInstance(DateTimeZone.forID("UTC"))));
    System.out.println("Julian: " + new DateTime(d, JulianChronology.getInstance(DateTimeZone.forID("UTC"))));
    System.out.println("Gregorian: " + new DateTime(d, GregorianChronology.getInstance(DateTimeZone.forID("UTC"))));

结果为:

Date: Fri Oct 15 00:00:00 GMT 1582 (-12219292800000 milliseconds)
ISO: 1582-10-15T00:00:00.000Z
Julian+Gregorian: 1582-10-15T00:00:00.000Z
Julian: 1582-10-05T00:00:00.000Z
Gregorian: 1582-10-15T00:00:00.000Z

所以唯一留下来的就是儒略历。那是所有尚未接受公历的国家/地区的有效日期,当时有很多国家/地区。希腊在 1923 年进行了转换...

在那之前的一毫秒,日期是:

    c.add(Calendar.MILLISECOND, -1);
    d = c.getTime();
    System.out.println("Date: " + d + " (" + d.getTime() + " milliseconds)");
    System.out.println("ISO: " + new DateTime(d, ISOChronology.getInstance(DateTimeZone.forID("UTC"))));
    System.out.println("Julian+Gregorian: " + new DateTime(d, GJChronology.getInstance(DateTimeZone.forID("UTC"))));
    System.out.println("Julian: " + new DateTime(d, JulianChronology.getInstance(DateTimeZone.forID("UTC"))));
    System.out.println("Gregorian: " + new DateTime(d, GregorianChronology.getInstance(DateTimeZone.forID("UTC"))));

含义:

Date: Thu Oct 04 23:59:59 GMT 1582 (-12219292800001 milliseconds)
ISO: 1582-10-14T23:59:59.999Z
Julian+Gregorian: 1582-10-04T23:59:59.999Z
Julian: 1582-10-04T23:59:59.999Z
Gregorian: 1582-10-14T23:59:59.999Z

ISO 和格里高利年表报告的日期在格里高利历中实际上并不存在,因为在 10 月 15 日之前没有格里高利历,但该日期在扩展的、预推的格里高利历中有效。这就像找到刻在公元前纪念碑上的公元前日期......在基督诞生之前,没有人知道他们在基督之前

因此,问题的根源在于日期字符串不明确,因为您不知道测量的是哪个日历。 5772 年是 future 的一年,还是当前的希伯来年? Java 采用 Julian+Gregorian 混合日历。 JodaTime 为不同的日历提供了广泛的支持,默认情况下它采用 ISO8601 年表。您的日期会自动从 1111 年使用的儒略历转换为我们当前使用的 ISO 年表。如果您希望 JodaTime 增强的时间戳使用与 java.sql.Timestamp 类相同的年表,那么在构造 JodaTime 对象时显式选择 GJChronology

关于java - 从 java.sql.Timestamp 到 joda 的 LocalDate 的意外转换,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/11146279/

相关文章:

java - 从日历到 Joda DateTime 的 JAXB 适配器

android - JodaTime 无法识别某些 Android 时区

java - putIfAbsent() 不适用于 ConcurrentHashMap

c# - 使用 C# RFID 包和 Java

java - 在 Android 应用程序中找不到 NullPointerException 的原因

java - cassandra 3 在启动期间在 debian docker 容器中抛出 Snitch 类异常

ios - 如何重置 iOS 日历中受限的 EK AuthorizationStatus?

javascript - 如何在javascript for循环中打印大括号

Java Joda时间多日期格式代码优化

java - 指定小时为 :minute, 但晚于现在的 Joda DateTime