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.
- 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.