I'm not sure there's anything we can do to improve this with how the product is set up. We just did some tests in the part to allow "31" to be typed instead of forcing it within the range of days within the current month (e.g. max 30 for June). That change allows you to type "31" in when the month is "06", however as soon as you switch focus to the month part, the control detects the active part changed, tries to parse a DateTime out of it, and ends up coercing the "31" back to a "30". This all happens in low-level generic PartEditBox logic so there's no easy way to work around it.
In the newer Editors we recently built for WinRT, we took a much simpler approach to editors where the editor is a freeform TextBox. It doesn't restrict what you type as you type it, yet you can still do up/down arrow keys to increment part values. The validation of the real backing DateTime occurs when you commit the value by either pressing Enter or losing focus. That particular more "lightweight" design means that the issue you describe isn't a problem there. Unfortunately we don't have lightweight variations of the editors in WPF though.