I’ll try to clear up possible confusion about dates and MySQL’s TO_DAYS() function. TO_DAYS() works, correctly. TO_DAYS() assumes a year 0, correctly. There are indeed bugs, but only if you use MySQL extensions with partitions.

First: TO_DAYS() works, correctly. The MySQL Reference Manual says we use a proleptic Gregorian calendar, and that’s all explained with terms anyone can follow, in section “11.7. What Calendar Is Used By MySQL?”
http://dev.mysql.com/doc/refman/5.1/en/mysql-calendar.html
So we follow the Gregorian rules, not the Julian ones, without concerning ourselves about what happened in 1582 — just like DB2, just like the standard, not like Oracle. To make sure it’s okay, I wrote and ran this stored procedure:

DELIMITER //
SET @@sql_mode=ansi//
DROP procedure IF EXISTS p//
CREATE PROCEDURE p ()
BEGIN
  DECLARE days_in_month INT DEFAULT 31;
  DECLARE months_in_year INT DEFAULT 12;
  DECLARE …

Starting with version 5.1.28, there is a new table INFORMATION_SCHEMA.PROFILING and a new statement SHOW PROFILE(S). Basic information is in the reference manual and in an introductory article. But I don’t think that’s adequate for everyone. I’ll try here to give some non-basic information. I’ll assume that you read the manual, think of this as a supplement.

A bit of a caveat: I was totally against adding this feature, and some of my bias might show. But I’m not trying to argue about it. I do believe that once we add a feature we should explain it, and all I’m trying to do is explain here.

How it works

The data-gathering code, or “instrumentation”, goes approximately like this:
statement_begin:
…

Long ago I wrote a 100-page book on MySQL 5.0 stored procedures. It’s on our dev-zone pages. But it’s out of date. In 2006 I made some corrections for MySQL 5.1. It took me a long time to publish the revised book, but here it is: http://blogs.mysql.com/peterg/files/2008/05/book01.pdf.