Solution
This long answer (to a question about practically the same bug) suggests a workaround for this issue.
Part of it quoted here:
formatDateRange()
does not work past 2038.Workaround #1
class DatePickerDialog1964 extends DatePickerDialog {
DatePickerDialog1964(Context c) {
super(c, null, 2013, 4, 21);
@SuppressWarnings("deprecation")
Date min = new Date(2013-1900, 4, 21);
DatePicker p = getDatePicker();
CalendarView cv = p.getCalendarView(); // should check for null
long cur = cv.getDate();
int d = cv.getFirstDayOfWeek();
p.setMinDate(min.getTime());
cv.setDate(cur + 1000L*60*60*24*40);
cv.setFirstDayOfWeek((d + 1) % 7);
cv.setDate(cur);
cv.setFirstDayOfWeek(d);
}
}
Workaround #2 I actually used
// Calendar view is a cascade of bugs.
// Work around that by explicitly disabling it.
datePicker.setCalendarViewShown(false);
My Deduction
By elimination, we can deduce that the line datePickerDialog.getDatePicker().setMinDate(Calendar.getInstance().getTimeInMillis() / 86400000L * 86400000L);
is causing the November 2100 error.
(UNIX time / 86400000L) * 86400000L
--I guess it's supposed to take advantage of rounding to produce a 'full' day. Beware of it rounding to the same day if the current time is after noon, the previous day if before. It isn't chopping after the floating point.
About the updated part:
Even calling setMinDate
then setDate
isn't really solving anything -- The problem that caused the Nov 2100 error will persist, because the updated line's effect is executed by the original code.
Then I looked around, and I found the above linked answer. I guess CalendarView is stuffed with bugs.
There appears to be another NumberPicker bug where the previous month and date and shown sometimes, even if not accessible. They disappear when we try to access them.
P.S: I know this is late, but since the OP didn't provide any solution, an analysis might be helpful to somebody.