Bug 7774 - Date property for DatePicker
Summary: Date property for DatePicker
Status: RESOLVED FIXED
Alias: None
Product: Android
Classification: Xamarin
Component: BCL Class Libraries ()
Version: 4.2.x
Hardware: PC Mac OS
: High enhancement
Target Milestone: ---
Assignee: Atsushi Eno
URL:
Depends on:
Blocks:
 
Reported: 2012-10-10 09:24 UTC by Timm
Modified: 2013-06-13 08:33 UTC (History)
2 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED FIXED

Description Timm 2012-10-10 09:24:16 UTC
The DatePicker control should have a Date property that accepts a .Net DateTime, so people don't have to use UpdateDate and remember the weird way in which Java handles the month number (though this is widely known, I would expect better from a C# API).

Would probably have prevented the related #3766.
Comment 1 Miguel de Icaza [MSFT] 2013-05-22 16:01:08 UTC
good observation, that is a hideous api.

We should think about what to do with the minimum/maximum dates properties as well, which take longs.
Comment 2 Atsushi Eno 2013-06-13 08:33:07 UTC
This is now added as *DateTime* property as well as MinDateTime and MaxDateTime for many reasons (1) it doesn't bring inconsistency between MinDate (long) and MaxDate (long) (2) it should work better with DateTimeOffset in the future if we want to bring it (depending on how DatePicker API updates it) and (3) considering what if Google brought Date class (of java.util or whatever they create), DateTime property is less likely to conflict.

DateTimePicker also got new UpdateDate(DateTime) method (overload to existing UpdateDate(int,int,int). OnDateUpdated(int,int,int) is unfixable, it's called from  Java side. We have DatePickerDialog.DateSetEventArgs.Date property which is of DateTime type (IMO it should have been named as DateTime property for the reasons above, but it's already in the stable API and cannot change that now).

They should become available in the next 4.7.x release.

[master 2fb5719]