What could possibility goes wrong if I were using deprecated Dates' method to see if they are in the same day?

Question

Currently, I have 2 Date objects. Both are generated in same device using same locale.

1 is generated using

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

Another is generated using

Date date2 = new Date();

Now, I would like to compare whether 2 dates are the same day.

According to Comparing two java.util.Dates to see if they are in the same day, I could use

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);

Since I'm running the code in mobile devices which resources are limited, I was wondering, what could possibility goes wrong, if I were using Date's deprecated method?

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

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

I know many people talk about Date alone doesn't handle internationalization well. But, in the above scenario, is there any solid example can prove that, thing can go wrong if I were using deprecated methods?

Why do you think using the right classes and methods would cause such a big resource consumption problem compared to using old deprecated methods? Just do the right thing, and optimize if you have a problem and have proved that the problem is caused by Calendar. — JB Nizet, Sep 28 '13 at 06:13
There are a few similar questions.... http://stackoverflow.com/questions/460423/why-was-new-dateint-year-int-month-int-day-deprecated — Pratik Shelar, Sep 28 '13 at 11:22
Also its not correct that Calendar API is resource intensive. The actual concept of date itself is complex and current generation of mobile devices can surely handle it. — Pratik Shelar, Sep 28 '13 at 11:24
Ya. Thanks for the info. But, can we just have a solid example to demonstrate what could go wrong? — Cheok Yan Cheng, Sep 28 '13 at 18:40

Stephen C · Answer 1 · 2014-06-09T07:19:10.407

For that specific example, it is unlikely that anything would go wrong. @Jim has a possible scenario, but it is an (extremely) edge case. And I suspect that you could run into the similare problems with other date / time APIs if you changed the default timezone at an inopportune time.

However, there are lots and lots of other (different) examples where things can go wrong when you use the Date APIs.

Now if you knew about all of the "tricks and traps" in the Date API and its implementation you could certainly avoid them, and safely use the deprecated methods. But:

how do you acquire that knowledge?
how do you know that you have acquired all of the knowledge that you need?
how do you know that the next guy who maintains your code will have the knowledge?

The reason that Date was deprecated was that the Java designers concluded that it was too difficult to use correctly, due to a number of design problems. IMO, it is best to respect their judgement.

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

I'm not aware of any hard evidence that the Calendar classes use significantly more resources than using Date. It is a bad idea to base your optimization decisions on mere supposition, especially if the optimizations have a definite risk of introducing new bugs. (And the fact that you are asking this Question, shows that you know there is a potential risk ...)

The best strategy is to avoid using deprecated classes and methods in new code. Period. And only optimize based on hard evidence.

score 0 · Answer 2 · answered Jun 09 '14 at 01:24

If you use the deprecated methods you could get a weird situation if someone changed the default Timezone elsewhere in code or by the device itself (introducing a side-effect problem). The normalize() method on java.util.Date depends on the Timezone remaining constant, if it's on mobile an example I can think of is when the user is abroad and a date was near midnight in the original timezone it could now potentially be treated as the day before (this might be desirable, but what about a Birthday)?. The big problem with using Date alone is it is really an Instant in time (fastTime is based on the long value set in millis), so it misleadingly represents both a Date and a Time. The best practice until Java 8 is to access date through the calendar so there is no ambiguity as to whether you are using a Date as a Date or a DateTime.

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);
    }

What could possibility goes wrong if I were using deprecated Dates' method to see if they are in the same day?

2 Answers2