I agree that that is a very strange behavior, but again all of the time functionality in the report comes from PHP and MySQL, which in turn take their orders from the server.
You can see it for yourself from lines 60 to 71 in admin/includes/classes/sales_report.php ...
Code:
// all our calculations are done using a "raw" timestamp format, which are
// pulled from entered date strings using the substr function (similar to zen_date_raw)
$this->sd_raw = mktime(0, 0, 0, substr($sd, 0, 2), substr($sd, 3, 2), substr($sd, 6, 4) );
$this->ed_raw = mktime(0, 0, 0, substr($ed, 0, 2), substr($ed, 3, 2), substr($ed, 6, 4) );
// run a few checks on the dates
// avoid dates before the first order
$first = $db->Execute("select UNIX_TIMESTAMP(min(date_purchased)) as date FROM " . TABLE_ORDERS);
$first_order = $first->fields['date'];
$this->global_sd = mktime(0, 0, 0, date("m", $first_order), date("d", $first_order), date("Y", $first_order));
if ($this->sd_raw < $this->global_sd) $this->sd_raw = $this->global_sd;
if ($this->ed_raw < $this->global_sd) $this->ed_raw = $this->global_sd;
The code certainly isn't doing anything different within the month of March, and I've never heard a report of an error like this. Based on this and my experience as a server admin, I think you really need to look at your server configuration. Start with the kernel's time keeping and DST settings, then look at Apache, MySQL, and PHP, in that order. A server swap would identify the source immediately, but that's obviously a little more involved.
I wish I could offer a better solution, but I will keep an eye out for similar issues.