Incorrect setting of date form element when passing date parts with leading zeroes.

The indentation needs to be fixed.

And is there anything particularly bad with requiring module code to properly cast a variable?

I came here in search for a previous bug report, before I wanted to report my own bug (fix).

In function expand_date in includes/form.inc:

1666c1666
<       '#value' => $element['#value'][$type],
---
>       '#value' => intval($element['#value'][$type]),

The bug affects dates in the form '02' to '09' (days 2 to 9 in the months Februar until September). There will be no "selected"-tag on these months/days in the select box.

The affected code looks a little different in 5.6, though. The expand_date function is still unchanged in 6.0-rc3. Somebody should fix this for 6.0-rc4 and 5.8.

This causes really bad behaviour i.e. in module Advanced Poll.

Well, I don't think this is a bug at all. The form API recognizes values when you specify them as they are in the options in the form. Make sure you convert/cast however it needs to be to get the same value. Feel free to discuss this more in Drupal 7.

Ok, you may be right. Still, you have to be very careful to write

$form['my_date'] = array(
  '#type' => 'date',
  '#default_value' => array('year' => date('Y', $date), 'month' => date('n', $date), 'day' => date('j', $date)),
);

instead of:

$form['my_date'] = array(
  '#type' => 'date',
  //  will fail on days/month from '02' to '09'
  '#default_value' => array('year' => date('Y', $date), 'month' => date('m', $date), 'day' => date('d', $date)),
);

I still think this should be changed, as SQL makes no difference between those types of dates.

I'm not convinced either way on this, but it needs a code comment to explain the cast to int and probably a test too.

Bumping to d8 the issue still applies.

Adding tag

Closing due to inactivity, and the fact that not everybody agreed this to be a bug. Feel free to reopen if there is an actionable fix (if it's even still an issue).