java如果我使用不推荐日期的方法来查看它们是否在同一天，会出现什么问题？

Question

目前，我有两个日期对象。两者都是在相同的设备中使用相同的语言环境生成的

1是使用

SimpleDateFormat FORMATTER = new SimpleDateFormat("EEE, dd MMM yyyy HH:mm:ss Z");
Date date1 = FORMATTER.parse(date_string);

另一个是使用

Date date2 = new Date();

现在，我想比较两个日期是否是同一天

根据Comparing two java.util.Dates to see if they are in the same day，我可以使用

Calendar cal1 = Calendar.getInstance();
Calendar cal2 = Calendar.getInstance();
cal1.setTime(date1);
cal2.setTime(date2);
boolean sameDay = cal1.get(Calendar.YEAR) == cal2.get(Calendar.YEAR) &&
                  cal1.get(Calendar.DAY_OF_YEAR) == cal2.get(Calendar.DAY_OF_YEAR);

由于我在资源有限的移动设备上运行代码，我想知道，如果我使用Date不推荐的方法，有什么可能出错

date1.getYear() == date2.getYear() && date1.getMonth() == date2.getMonth() && date1.getDate() == date2.getDate()

http://user.xmission.com/~goodhill/dates/datedeprecation.htm

我知道很多人都说Date单靠Date并不能很好地处理国际化问题。但是，在上面的场景中，是否有任何可靠的例子可以证明，如果我使用不推荐的方法，事情可能会出错

Answer 1

就这一具体例子而言，不太可能出现任何问题@吉姆有一个可能的情况，但这是一个（极端）边缘的情况。我怀疑如果在不合适的时间更改默认时区，您可能会遇到与其他日期/时间API类似的问题

然而，当您使用Dateapi时，有很多其他（不同的）例子可能会出错

现在，如果您了解DateAPI中的所有“技巧和陷阱”及其实现，您当然可以避免它们，并安全地使用不推荐的方法。但是：

• 你是如何获得这些知识的
• 你怎么知道你已经获得了所有你需要的知识
• 你怎么知道下一个维护你的代码的人会知道呢

不推荐使用Date的原因是Java设计人员认为由于许多设计问题，很难正确使用。在国际海事组织，最好尊重他们的判断

Since I'm running the code in mobile devices which resources are limited ...

我不知道有任何确凿的证据表明Calendar类比使用Date类使用的资源要多得多。将优化决策建立在纯粹的假设基础上是一个坏主意，尤其是当优化有引入新bug的明确风险时。（你问这个问题的事实表明，你知道存在潜在风险…）

最好的策略是避免在新代码中使用不推荐的类和方法。时期而且只能根据确凿的证据进行优化

Answer 2

如果使用不推荐的方法，如果有人在代码中的其他地方或设备本身更改了默认时区，则可能会出现奇怪的情况（引入副作用问题）。java上的normalize（）方法。util。日期取决于时区保持不变，如果它在移动设备上，我可以想到的一个例子是，当用户在国外，并且日期在原始时区接近午夜时，它现在可能被视为前一天（这可能是可取的，但生日呢）？。单独使用Date的最大问题是它实际上是时间上的一个瞬间（fastTime基于以毫秒为单位设置的长值），因此它误导性地表示日期和时间。在Java8之前的最佳实践是通过日历访问日期，因此对于使用日期作为日期还是日期时间没有任何歧义

private final BaseCalendar.Date normalize() {
    if (cdate == null) {
        BaseCalendar cal = getCalendarSystem(fastTime);
        cdate = (BaseCalendar.Date) cal.getCalendarDate(fastTime,
                                                        TimeZone.getDefaultRef());
        return cdate;
    }

    // Normalize cdate with the TimeZone in cdate first. This is
    // required for the compatible behavior.
    if (!cdate.isNormalized()) {
        cdate = normalize(cdate);
    }

    // If the default TimeZone has changed, then recalculate the
    // fields with the new TimeZone.
    TimeZone tz = TimeZone.getDefaultRef();
    if (tz != cdate.getZone()) {
        cdate.setZone(tz);
        CalendarSystem cal = getCalendarSystem(cdate);
        cal.getCalendarDate(fastTime, cdate);
    }