There is a bug with your code.
In your test case for master try removing the default values and instead setting a value for the fields through $mform->set_value().
By doing that I generated several notes like:
Notice: Undefined index: month in /var/www/integration/lib/form/dateselector.php on line 234
Looking at the output and debugging the values I can see that before your change the values for day and month are not prefixed by a 0 for single digits, and after your changes sometimes they are and sometimes they are not. Looks like a bug with usergetdate that will be highlighted by this change. Not necessarily related. But definitely a blocker.
On the flip side I asked Dan to have a look at this issue for me as I am very suspicious of the changes and he was aware of
MDL-32234, the exact issue I had noticed and one that you had also fixed. Dan has now linked the issue.
I turned this up while trying to research the effects of this change.
Its a small but potentially significant change in that we are now using timezone when updating a value, and using it again when returning the value.
To compound it this change is to be made to a pretty well used bit of code and the only test case is a test script that worked even when there were issues.
Could you please double check everything for me, and find some test cases in Moodle. I assume those dst and timezone arguments are being used and it would be great to identify existing areas that do use them and focus on those for testing.
I've chosen to leave this in integration atm, however I will ask Eloy to look at it when he comes online as he is much more familiar with timezone handling than I am.