Fixes #636. Prevents losing days when using date columns in certain timezones.

The problem is pretty complex. Say we have a `data` column in MySQL and an input string like `2012-05-12 00:00:00 Z` as in the unit test.

In a time zone like CET (UTC+1), passing this string to the `Date` constructor will give a `Date` object in the local time zone, i.e. `Sat May 12 2012 01:00:00 GMT+0100 (CET)`. If this is stored in the database, it will be truncated to `2012-05-12` (which is the correct day). When it is fetched from the database, it will be assumed that the time is 00:00:00 *and* UTC, so we will end up with exactly the same date as when parsing the input string.

In a time zone like EDT (UTC-4), passing the same string to the `Date` constructor will also give a Date object in the local time zone, i.e. `Fri May 11 2012 20:00:00 GMT-0400 (EDT)`. If this is stored in the database, it will be truncated to `2012-05-11` (which is different than before, but we can argue this is correct behavior, since in a EDT place, the point in time described by the input string *is* May 11). However, when it is fetched from the database, it will be assumed that the time is 00:00:00 *and* UTC, and parsing `2012-05-11 00:00:00` in EDT will give `Thu May 10 2012 20:00:00 GMT-0400 (EDT)`, i.e., we lose one day - which is what @iarna observed.

In order to deal with that, after parsing a `date` string in a time zone with a positive offset compared to UTC (i.e., UTC-*x*), I add 24 hours to get back the original time stamp that we put in. This should fix the issue that @iarna reported.

Can someone please comment on that before merging in?