I have confirmation from MathWorks support of the following bug in the JDBC driver used by (at least) the Windows 64-bit R2012b Database Toolbox: datetimes falling within the hours lost (gained) due to the change to (from, respectively) Daylight Savings Time are quietly and unilaterally adjusted for DST, even if the target data-type is supposed to be time zone and DST "agnostic," e.g., SQL Server's datetime2 data-type. For example, if you query a SQL Server datetime2 field whose value is '2011-03-13 02:00:00' (which doesn't exist in (at least) US DST-observing locales, but is a valid value in UTC, as well as in places that don't observe the US DST change-over), Matlab will return '2011-03-13 03:00:00' (I don't know if this is location/configuration dependent: if your computer's time configuration has "adjust for DST" turned off, perhaps you won't see this behavior). The advertised workaround is to query for the value cast as a varchar (or equivalent), and then convert to a datetime-type in Matlab.
What I would like to know: has anyone else here observed this bug yet?
Thanks for your time; hope this helps someone(s) have a little less frustration than I've had. ;-)