Ooo.. something I can actually speak to. While I don't know the reason WHY they did it, I know I've run into the "one digit day" problem before (same thing with Month). The date format standard is YYYY-MM-DDTHH:MM:SS. This allows for ANY date to be represented and parsing it is a cake walk.

A given data call for our website returns XML, which just gets passed on up the layers/tiers to the XSL. Dates get returned in one, standard format (YYYY-MM-DDTHH:MM:SS). Sure they could add parameters in every stored procedure that returns a date to specify the format the requestor wants... but that's a maintenance headache. So they always return dates the same. Not much of a problem for programming languages that have some Date() object, but for non-programming languages, like XSL, that date value is a string and has to be parsed.

EXAMPLE:
You have a web page that shows some dates retrieved from the database. Those dates are 1/1/2004, 6/30/2004, 10/1/2004, and 12/31/2004.

However, since they're stored as datetime's in SQL they all come back in YYYY-MM-DDTHH:MM:SS format. So they would be represented thusly:

2004-01-01T00:00:00
2004-06-30T00:00:00
2004-10-01T00:00:00
2004-12-31T00:00:00

See how nice and neat they are? Easy to parse in XSL. You can ALWAYS grab the day with "sub-string(dtFoo, 9, 2)" (starts at the ninth character of the dtFoo string and grabs characters). Months are always "sub-string(dtFoo, 6, 2)". Years, hours, minues, seconds always where you want them.

However, those dates got put into a Date object whose system time format got changed to leave off the preceding 0 for values less than 10 and then passed out a web service... the dates might look like this:

2004-1-1T00:00:00
2004-6-30T00:00:00
2004-10-1T00:00:00
2004-12-31T00:00:00

Now my XSL is broken, or I'll have to come up with four separate ways for grabbing each interval that I want.

So, I have one word for you ... STANDARDS!!!