If:
- Format is set to Custom
- FormatString to a custom format that does not have (mili)seconds (i.e. dd-MMM-yyyy HH:mm)
- Value (bound) is null
Then:
- If user clicks the up/down buttons (without opening the calender), Value is set to a new DateTime with the current date/time, but with seconds and milisecond fields filled in (i.e. <> 0). Thus, the custom frmat is ignored. If user enters via typing in or selecting via calender, the (mili)second fields ARE set to 0, which seems the better behavior.
- In the above scenario, the DateTime.Kind property is set to Local, while else it's set to Unspecified. This is unwanted if you have to convert in to other TimeZones.
Comments: ** Comment from web user: BoucherS **
- Format is set to Custom
- FormatString to a custom format that does not have (mili)seconds (i.e. dd-MMM-yyyy HH:mm)
- Value (bound) is null
Then:
- If user clicks the up/down buttons (without opening the calender), Value is set to a new DateTime with the current date/time, but with seconds and milisecond fields filled in (i.e. <> 0). Thus, the custom frmat is ignored. If user enters via typing in or selecting via calender, the (mili)second fields ARE set to 0, which seems the better behavior.
- In the above scenario, the DateTime.Kind property is set to Local, while else it's set to Unspecified. This is unwanted if you have to convert in to other TimeZones.
Comments: ** Comment from web user: BoucherS **
Hi,
v2.4 should fix theses issues.