I'm debugging an issue where the CalendarView
in a DatePicker
moves to October 1964 if there is a non-default minimum date set. This reproduces at least on API17 Nexus7 emulator but there are reports about this issue on other devices where the platform style includes both spinners and calendar view in date picker.
Here's a code snippet demonstrating the issue:
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();
p.setMinDate(min.getTime());
}
}
...
new DatePickerDialog1964(context).show();
Screen shot:
Of course, the expectation is that the spinners and calendar view would be showing the same date.
I'll keep on debugging this but if any SO users have experience or other insight, please share.
Related:
- Issue 42750: CalendarView initially scrolls to year 1964
- using CalendarView to pick a date in future (android-developers)
TL;DR
It's not 1964 but 2100 formatted badly. CalendarView
has bugs. 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);
Analysis
CalendarView
uses android.text.format.DateUtils.formatDateRange()
for producing the month/year name in the header. Calendar view only updates the header when the month number changes. For example, if the month number is the same but the year changes, the header is not updated.
Somewhere during layout phase, the underlying ListView
invokes OnScrollListener
on the calendar view as if the list was scrolled to the end. If the month number is changed, the header is updated with the test code above, the millis value passed to formatDateRange()
is 4131043200000
which is somewhere in late 2100, and 2100 is the default maximum for DatePicker
.
formatDateRange()
in turn uses android.text.format.Time
as its internal calendar representation, specifically setting the millis using its set()
method. I did not check the underlying native code, but my educated guess is that the passed in milliseconds value gets truncated to 32-bit time_t
seconds value with the inherent Year 2038 problem, wrapping to a value of a little more than 62 years. Time
itself is using struct tm
which represents years as an int
since 1900, thus resulting in a Time
in the 1960s which then gets formatted in the header.
This can be reproduced with plain DatePicker
with CalendarView
without min date set. Just use the spinners to move the year to 2038 or later, change the month (to trigger the header update) and you'll see the year in header wrap to 1902.
Now, the question remains why setting a minimum date makes the calendar view scroll to maximum date. Answer seems to be the calendar view's week ListView
adapter. It indexes weeks from the minimum date, but when the minimum date changes, the adapter's notifyDataSetChanged()
is not called. So the workaround #1 above works because:
- Changing the date by more than a month makes the month header change.
- Changing the first day of week makes the week listview notice its adapter's data has changed.
The above answers are right on about the sources of this bug. For my application, I'm using this workaround:
Every time the DatePicker's date or minDate is changed, call the following routine with the date that should be selected in the picker/calendar:
private void fixUpDatePickerCalendarView(Calendar date) {
// Workaround for CalendarView bug relating to setMinDate():
// https://code.google.com/p/android/issues/detail?id=42750
// Set then reset the date on the calendar so that it properly
// shows today's date. The choice of 24 months is arbitrary.
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {
final CalendarView cal = datePicker.getDatePicker().getCalendarView();
if (cal != null) {
date.add(Calendar.MONTH, 24);
cal.setDate(date.getTimeInMillis(), false, true);
date.add(Calendar.MONTH, -24);
cal.setDate(date.getTimeInMillis(), false, true);
}
}
}
The solution that I ended up using:
private void fixBuggyCalendarview(CalendarView cv) {
long current = cv.getDate();
cv.setDate(cv.getMaxDate(), false, true);
cv.setDate(current, false, true);
}
This also works when you have set min/max date for the CalendarView
I agree with @laalto. The original CalendarView
is a total mess. I also had problems with the locales, the font size on Android 4.1.2 (oh yeah and it was shifted down), the lack of accessibility features, etc. So I decided to copy the source code and implement my own calendar. For example, now the header text is displayed correctly.
/**
* The source code has the Year 2038 problem and doesn't honor CalendarView's mCurrentLocale.
*/
private void setMonthDisplayed(Calendar calendar) {
mMonthName.setText(DateFormat.format("MMMM, yyyy", calendar));
mMonthName.invalidate();
mCurrentMonthDisplayed = calendar.get(Calendar.MONTH);
mAdapter.setFocusMonth(mCurrentMonthDisplayed);
}
/**
* This imlementation formats the date correctly and uses the stand-alone form of a month (for the languages where it's important).
*/
private void setMonthDisplayed(Calendar calendar) {
mMonthName.setText(new SimpleDateFormat("LLLL yyyy", mCurrentLocale).format(calendar.getTime()));
mMonthName.invalidate();
mCurrentMonthDisplayed = calendar.get(Calendar.MONTH);
mAdapter.setFocusMonth(mCurrentMonthDisplayed);
}
Before implementing any of the suggestions above, check to make sure that your simulator is running on today's date and time. If left open for a while, it can lag by a few days. I fixed my issue simply by restarting the simulator.