added a comment - - edited
ok, Ive attached patches to moodlelib.php and testmoodlelib.php for everyone to have a look at. Let me know if I've done anything silly 
I added some unit tests. The changes I made to usergetdate() itself were a little more invasive than I expected. I wrote the unit tests testing the return array with and without a time zone then modified usergetdate() as necessary to get the returned array to be basically identical.
The core of moodle shouldn't be affected at all by these changes. I've looked through every call and they're all accessing the array using keys like this...
$thisdate = usergetdate(time());
echo($thisdate['mon']);
The alternative is something like this.
list($seconds,$minutes,$hours,$mday,$wday,$mon,$year,$yday,$weekday,$month) = usergetdate(time());
I would recommend NOT doing it this way. Any changes in the array order will cause the wrong values to wind up in the wrong variables which could have all sorts of hard to track down side effects. The unit tests should catch that but... Note that the unit tests do it this way so that they document the order of things if you are going to do it this way.
As I documented in the thread where this bug report was spawned, I believe this is a result of the core Moodle function usergetdate (in lib/moodlelib.php) returning data in a different order if the time zone is not set in Moodle. If I am correct, then this should be moved from a CONTRIB bug to a MDL bug.
The short-term solution is to change usergetdate to reorder the return when the time zone has not been set. However, the more reasonable (yet far more intensive change because it requires changing the code in every piece of code that calls usergetdate) is to change the order of data returned when a user has set the time zone to match the default order that PHP returns with its getdate function.