Allow to remove delimiters for DateSelect and fix bugs with some locales

[bakura10]

This is a fix for #3694

ping @wryck7 and @grizzm0, could you tell me if it solves your issue ?

[weierophinney]

Merged to develop, as it introduces new methods and thus new behaviors.

[bakura10]

I think it should be merged into master instead. It mainly fix a bug that would make both DateTimeSelect/DateSelect/MonthSelect not working with some locales like es_ES, pt_BR...

[weierophinney]

Done.

[iquabius]

In my case it's working - because I disabled 'render_delimiters'. But if someone needs the delimiters with es_ES or pt_BR, the delimiters will be wrong. See the exemples:

The pattern for es_ES and pt_BR is "d 'de' MMMM 'de' y", but when rendering, the helper outputs:

    <select name="day">...</select> '' <select name="month"> '' <select name="year">

note: The delimiters should be de (without single quotes arround) insted of ''

This is happening because the regex in the parsePattern() method, when $pattern = "d 'de' MMMM 'de' y", the $pregResult will be something like this:

array(9) {
  [0]=>
  string(1) "d"
  [1]=>
  string(2) " '"
  [2]=>
  string(2) "de"
  [3]=>
  string(2) "' "
  [4]=>
  string(4) "MMMM"
  [5]=>
  string(2) " '"
  [6]=>
  string(2) "de"
  [7]=>
  string(2) "' "
  [8]=>
  string(1) "y"
}

[iquabius]

I just noticed another problem, when using formDateSelect() with locale pt_BR or es_ES, the helper generate a weird array of options for the days, this is what I get from the method getDaysOptions():

array(31) {
  ["01"]=>
  string(2) "15"
  ["02"]=>
  string(2) "26"
  ["03"]=>
  string(2) "37"
  ["04"]=>
  string(2) "41"
  ["05"]=>
  string(2) "52"
  ["06"]=>
  string(2) "63"
  ["07"]=>
  string(2) "74"
  ["08"]=>
  string(2) "85"
  ["09"]=>
  string(2) "96"
  [10]=>
  string(3) "107"
  [11]=>
  string(3) "111"
  [12]=>
  string(3) "122"
  [13]=>
  string(3) "133"
  [14]=>
  string(3) "144"
  [15]=>
  string(3) "155"
  [16]=>
  string(3) "166"
  [17]=>
  string(3) "177"
  [18]=>
  string(3) "181"
  [19]=>
  string(3) "192"
  [20]=>
  string(3) "203"
  [21]=>
  string(3) "214"
  [22]=>
  string(3) "225"
  [23]=>
  string(3) "236"
  [24]=>
  string(3) "247"
  [25]=>
  string(3) "251"
  [26]=>
  string(3) "262"
  [27]=>
  string(3) "273"
  [28]=>
  string(3) "284"
  [29]=>
  string(3) "295"
  [30]=>
  string(3) "306"
  [31]=>
  string(3) "317"
}

And this is happening because of the parsePattern() as well.

[bakura10]

It looks like the keys are ok... This is driving me crazy :'(. I'll try to have a look tomorrow (or please check it, it must be a stupid error...).

[grizzm0]

Do we really need Intl to render most of this stuff? I think it's a bit overkill. The only Intl use for days, hours, minutes and seconds would be to see if 0-9 should be double digit (not sure how that's handled in different locales).

[bakura10]

That's an idea too. I think it'll be easier. I initially did that because I asked myself if some locale used "01" or "1".

[iquabius]

I sent a PR here, take a look!