WAI
Status Update
Comments
al...@android.com <al...@android.com>
no...@contactspls.com <no...@contactspls.com> #3
Bug is traceable for me.
no...@contactspls.com <no...@contactspls.com> #4
I encountered this bug as well on Nexus 7 running 4.2.2 [JDQ39]. A workaround was changing the date (CalenderView.setDate) after minDate was set (using a different date then previously set).
ki...@gmail.com <ki...@gmail.com> #5
I encountered a similar issue and debugged it further:
- It's not 1964 but the max date 2100 with Y2k38 issues, DateUtils.formatDateRange() uses android.text.format.Time which seems to be using a 32-bit time_t and cannot format dates past 2038 correctly.
- The month+year header is only updated when the month of year changes, regardless of any other changes in calendar. Especially bad for e.g. tablet DatePicker where there's both the spinners and calendar view: adjusting the date with spinners only affects the header if month is changed, changing the year has no effect. Workaround for this is to temporarily tweak the date by at least a month.
- Setting min date on calendar view changes the underlying ListView's WeeksAdapter but WeeksAdapter.init() does not call notifyDataSetChanged() so the listview will be off by new_mindate-old_mindate and thus the "current view" will be around the default max date of 2100, rendered as 1964. For example setFirstDayOfWeek() will call notifyDataSetChanged() on the adapter so a workaround for this is to temporarily tweak the first day of week setting.
More info in my StackOverflow question and answer:http://stackoverflow.com/questions/16664562/setting-mindate-on-datepicker-moves-calendarview-to-1964
- It's not 1964 but the max date 2100 with Y2k38 issues, DateUtils.formatDateRange() uses android.text.format.Time which seems to be using a 32-bit time_t and cannot format dates past 2038 correctly.
- The month+year header is only updated when the month of year changes, regardless of any other changes in calendar. Especially bad for e.g. tablet DatePicker where there's both the spinners and calendar view: adjusting the date with spinners only affects the header if month is changed, changing the year has no effect. Workaround for this is to temporarily tweak the date by at least a month.
- Setting min date on calendar view changes the underlying ListView's WeeksAdapter but WeeksAdapter.init() does not call notifyDataSetChanged() so the listview will be off by new_mindate-old_mindate and thus the "current view" will be around the default max date of 2100, rendered as 1964. For example setFirstDayOfWeek() will call notifyDataSetChanged() on the adapter so a workaround for this is to temporarily tweak the first day of week setting.
More info in my StackOverflow question and answer:
ch...@google.com <ch...@google.com> #6
DateUtils.formatDateRange has been using Calendar (which doesn't have y2k38 problems) for a while now. is this still a problem in jb-mr2?
ki...@gmail.com <ki...@gmail.com> #7
I am seeing this issue still occurring on select devices (Sony Xperia tablet, Samsung Nexus tablet) but I am not able to get the linked SO answer to solve the issue on the Sony Xperia.
va...@gmail.com <va...@gmail.com> #8
I am using API 19 and I still have this issue.
Easy way to reproduce it:
DatePickerDialog datePickerDialog = new DatePickerDialog(this, null, 2014, 2, 2);
datePickerDialog.getDatePicker().setMinDate(1391288362112L);
datePickerDialog.show();
Easy way to reproduce it:
DatePickerDialog datePickerDialog = new DatePickerDialog(this, null, 2014, 2, 2);
datePickerDialog.getDatePicker().setMinDate(1391288362112L);
datePickerDialog.show();
[Deleted User] <[Deleted User]> #9
Another way to reproduce the problem.
Just use this:
<DatePicker
android:id="@+id/datePicker1"
android:minDate="01/01/2020"
android:layout_width="wrap_content"
android:layout_height="wrap_content" />
Just use this:
<DatePicker
android:id="@+id/datePicker1"
android:minDate="01/01/2020"
android:layout_width="wrap_content"
android:layout_height="wrap_content" />
gi...@gmail.com <gi...@gmail.com> #10
Holy shit how could this be possible?!?! this is a fu****g basic component needed for almost ANY app in the world, how could it be so buggy?!?! :/
Google you suck!!!
Google you suck!!!
sw...@gmail.com <sw...@gmail.com> #11
Problem still exists in Android 5.1 (API 22).
no...@contactspls.com <no...@contactspls.com> #12
Even calling CalendarView methods with notifyDataSetChanged() the bug is still here: setting minDate displays year 2100.
Is there any estimate for when this class will be usable?
Is there any estimate for when this class will be usable?
di...@gmail.com <di...@gmail.com> #13
You can work-around this bug by doing the following:
Use getActivity().runonUiThread() to do the following when the GUI has finished being populated:
spawn a new, async thread.
In the async thread, wait a moment, scroll to 2 months past your wanted date, wait a moment, scroll to your initial wanted date.
Be sure to change the date using the main thread, by using runonuithread() from your async thread.
Use getActivity().runonUiThread() to do the following when the GUI has finished being populated:
spawn a new, async thread.
In the async thread, wait a moment, scroll to 2 months past your wanted date, wait a moment, scroll to your initial wanted date.
Be sure to change the date using the main thread, by using runonuithread() from your async thread.
di...@gmail.com <di...@gmail.com> #14
It has been four years and the bug is still there.
android 6.0.1 api 23
If I call setMinDate(), the calendarview shows Nov 2100.
android 6.0.1 api 23
If I call setMinDate(), the calendarview shows Nov 2100.
ij...@gmail.com <ij...@gmail.com> #15
Unbelievable, but the bug is actual yet ! Hey, Google, are you ok with that ?
tr...@gmail.com <tr...@gmail.com> #16
I have users are still reporting me that Calendar is displaying year 2100 when I set minDate.
Is there some solution or workround to solve it?
Is there some solution or workround to solve it?
da...@gmail.com <da...@gmail.com> #17
Thank you for your feedback. We assure you that we are doing our best to address all issues reported. For now, we will be closing the issue as won't fix obsolete. If this issue currently still exists, we request that you log a new issue along with the bug report here https://goo.gl/TbMiIO and reference this bug for context.
Description
Version used:
com.android.support:design:22.2.0
com.android.support:appcompat-v7:22.2.0
com.android.support:recyclerview-v7:22.2.0
We have an activity with an AppBarLayout, ViewPager containing fragments - each holding a RecyclerView.
The ViewPager is using AppBarLayout.ScrollingViewBehavior.
in fragment A we have a bottom view without any scroll flags - when we scroll the RecyclerView the coordinator layout hides/shows the AppBarLayout as well as our footer.
Expected behavior : the bottom view should be always visible