我遇到了一个奇怪的行为，这让我很好奇，但目前还没有令人满意的解释。

为简单起见，我将我注意到的症状简化为以下代码:

import java.text.SimpleDateFormat;
import java.util.GregorianCalendar;

public class CalendarTest {
    public static void main(String[] args) {
        System.out.println(new SimpleDateFormat().getCalendar());
        System.out.println(new GregorianCalendar());
    }
}

当我运行这段代码时，我得到了与以下输出非常相似的东西:

java.util.GregorianCalendar[time=-1274641455755,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="America/Los_Angeles",offset=-28800000,dstSavings=3600000,useDaylight=true,transitions=185,lastRule=java.util.SimpleTimeZone[id=America/Los_Angeles,offset=-28800000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=1929,MONTH=7,WEEK_OF_YEAR=32,WEEK_OF_MONTH=2,DAY_OF_MONTH=10,DAY_OF_YEAR=222,DAY_OF_WEEK=7,DAY_OF_WEEK_IN_MONTH=2,AM_PM=1,HOUR=8,HOUR_OF_DAY=20,MINUTE=55,SECOND=44,MILLISECOND=245,ZONE_OFFSET=-28800000,DST_OFFSET=0]
java.util.GregorianCalendar[time=1249962944248,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="America/Los_Angeles",offset=-28800000,dstSavings=3600000,useDaylight=true,transitions=185,lastRule=java.util.SimpleTimeZone[id=America/Los_Angeles,offset=-28800000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2009,MONTH=7,WEEK_OF_YEAR=33,WEEK_OF_MONTH=3,DAY_OF_MONTH=10,DAY_OF_YEAR=222,DAY_OF_WEEK=2,DAY_OF_WEEK_IN_MONTH=2,AM_PM=1,HOUR=8,HOUR_OF_DAY=20,MINUTE=55,SECOND=44,MILLISECOND=248,ZONE_OFFSET=-28800000,DST_OFFSET=3600000]

(如果我向 SimpleDateFormat 提供像 "yyyy-MM-dd" 这样的有效格式字符串，也会发生同样的事情。)

请原谅可怕的非换行，但这是比较两者的最简单方法。如果滚动到大约 2/3 处，您会看到日历的 YEAR 值分别为 1929 年和 2009 年。 (还有一些其他差异，例如一年中的星期、星期几和 DST 偏移量。)两者显然都是 GregorianCalendar 的实例，但它们不同的原因令人费解。

据我所知，格式化程序在格式化传递给它的 Date 对象时会产生准确的结果。显然，正确的功能比正确的引用年份更重要，但这种差异仍然令人不安。我不认为我必须在全新的日期格式化程序上设置日历才能获得当前年份...

我在装有 Java 5(OS X 10.4、PowerPC)和 Java 6(OS X 10.6、Intel)的 Mac 上进行了测试，结果相同。由于这是一个 Java 库 API，我假设它在所有平台上的行为都相同。对这里正在发生的事情有任何见解吗？

(注:This SO question有点相关，但不一样。)

编辑:

下面的答案都有助于解释这种行为。结果是 SimpleDateFormat 的 Javadocs实际上在某种程度上记录了这一点:

"For parsing with the abbreviated year pattern ("y" or "yy"), SimpleDateFormat must interpret the abbreviated year relative to some century. It does this by adjusting dates to be within 80 years before and 20 years after the time the SimpleDateFormat instance is created."

因此，他们没有看中被解析日期的年份，而是默认将内部日历设置为 80 年。该部分本身没有记录，但当您了解它时，所有部分都可以组合在一起。

最佳答案

我不确定为什么汤姆说“这与序列化有关”，但他说对了:

private void initializeDefaultCentury() {
    calendar.setTime( new Date() );
    calendar.add( Calendar.YEAR, -80 );
    parseAmbiguousDatesAsAfter(calendar.getTime());
}

它是 SimpleDateFormat.java 中的第 813 行，在这个过程中已经很晚了。到那时为止，年份是正确的(日期部分的其余部分也是如此)，然后减去 80。

啊哈!

对 parseAmbiguousDatesAsAfter() 的调用与 set2DigitYearStart() 调用的私有(private)函数相同:

/* Define one-century window into which to disambiguate dates using
 * two-digit years.
 */
private void parseAmbiguousDatesAsAfter(Date startDate) {
    defaultCenturyStart = startDate;
    calendar.setTime(startDate);
    defaultCenturyStartYear = calendar.get(Calendar.YEAR);
}

/**
 * Sets the 100-year period 2-digit years will be interpreted as being in
 * to begin on the date the user specifies.
 *
 * @param startDate During parsing, two digit years will be placed in the range
 * <code>startDate</code> to <code>startDate + 100 years</code>.
 * @see #get2DigitYearStart
 * @since 1.2
 */
public void set2DigitYearStart(Date startDate) {
    parseAmbiguousDatesAsAfter(startDate);
}

现在我明白是怎么回事了。彼得在他关于“苹果和橘子”的评论中是对的! SimpleDateFormat 中的年份是“默认世纪”的第一年，两位数年份字符串(例如，“1/12/14”)被解释为的范围。参见 http://java.sun.com/j2se/1.4.2/docs/api/java/text/SimpleDateFormat.html#get2DigitYearStart%28%29 :

因此，为了“效率”胜于清晰，SimpleDateFormat 中的年份用于存储“解析两位数年份的 100 年期间的开始”，而不是当前年份!

谢谢，这很有趣——终于让我安装了 jdk 源(我的 / 分区上只有 4GB 的总空间。)

关于java - 为什么新的 SimpleDateFormat 对象包含错误年份的日历？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1258441/