[Yaml] Fixed double quotes escaping in Dumper.
[Form] fixed a bug that caused input date validation not to be strict when using the single_text widget with a date field
[Form] fixed a bug that caused input date validation not to be strict when using the single_text widget with a datetime field
Add 5.3.3 to Travis, now is available.
merged branch Maks3w/patch-3 (PR #4442)

Commits
-------

face1f1 Add 5.3.3 to Travis, now is available.

Discussion
----------

Add 5.3.3 to Travis, now is available.

---------------------------------------------------------------------------

by travisbot at 2012-05-28T12:41:45Z

This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1455374) (merged face1f1b into cc42a187).

---------------------------------------------------------------------------

by fabpot at 2012-05-28T14:03:29Z

The minimum PHP version has been changed for Symfony 2.1, not for 2.0.

---------------------------------------------------------------------------

by vicb at 2012-05-28T14:29:37Z

but 5.3.2 is not available on travis, @Maks3w right ?

---------------------------------------------------------------------------

by Maks3w at 2012-05-28T14:33:05Z

@vicb 5.3.2 is not available on Travis.

@fabpot Then you can merge #4439, it's the same but for master

---------------------------------------------------------------------------

by vicb at 2012-05-28T14:43:33Z

why not keep 5.3.3 for 2.0 also (closer to 5.3.2 than just 5.3 which is 5.3.13 - best we can do).
merged branch iteman/date-validation-with-singletext-form-fix (PR #4434)

Commits
-------

20b556d [Form] fixed a bug that caused input date validation not to be strict when using the single_text widget with a datetime field
7e3213c [Form] fixed a bug that caused input date validation not to be strict when using the single_text widget with a date field

Discussion
----------

[Form] fixed a bug that caused input date validation not to be strict when using the single_text widget with a date/datetime field

Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
License of the code: MIT
Documentation PR: -

Currently, input date validation is not strict when using the single_text widget with a date or datetime field. This will cause unexpected transformation of input date value as follows:

* 2012-04-31 => 2012-05-01
* 2012-04-31 03:04:00 => 2012-05-01 03:04:00

Additionally this is not same as other transformation logic for date/datetime fields because they use the checkdate() function to validate input date values. The checkdate() function validates a date strictly.

```php
<?php
var_dump(checkdate(4, 31, 2012)); // bool(false)
```

BTW, the documentation of [IntlDateFormatter::setLenient()](http://php.net/manual/en/intldateformatter.setlenient.php) and [IntlDateFormatter::isLenient()](http://php.net/manual/en/intldateformatter.islenient.php) have been fixed recently. Please see https://bugs.php.net/bug.php?id=61896 **The default parser is lenient, not strict**.

---------------------------------------------------------------------------

by travisbot at 2012-05-28T07:35:11Z

This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1453681) (merged 20b556da into 167779e5).

---------------------------------------------------------------------------

by bschussek at 2012-05-28T09:25:23Z

Quote on strict parsing:

> Extra space, unrecognized tokens, or invalid values ("February 30th") are not accepted.

Disabling lenient parsing makes entering dates in text boxes even harder than it is right now.

---------------------------------------------------------------------------

by iteman at 2012-05-29T09:31:49Z

In my opinion, in most applications, in particular enterprise applications, date/time handling is very important. Unexpected transformation of date/time may sometimes lead unexpected outcomes. In such applications, accepting invalid values is not important than avoiding unexpected transformation. **As specifications, "strict" should be the default, or at least, the "strict" option should be provided if the default is "lenient".**

Moving on to the current behavior.

If "lenient" is intended behavior, is there any way to know it? At least, there is nothing to be found in the tests and documentation for the date/datetime field.

http://php.net/manual/en/intldateformatter.setlenient.php:

> Extra space, unrecognized tokens, or invalid values ("February 30th") are not accepted.

This is only applicable to *DateTimeToLocalizedStringTransformer* (using *IntlDateFormatter*) that is used by *DateType*, not applicable to *DateTimeToStringTransformer* (using *DateTime*) that is used by *DateTimeType*. Why is defferent between these implementation in the first place?

On the one hand, strict validation by *checkdate()* has been adopted in the widgets except the single_text widget. Does this conflict with the single_text widget? Isn't there any problem to be determined "lenient" or "strict" by the widget type mainly from the point of view of the separation of concerns?

Additionally, is there any way to avoid unexpected transformation in the current behavior without changing the specification of a domain object, or writing a new transfer object, or not using the single_text widget?

Finally, I think that the current behavior is bad, but if the current behavior is not a bug, I think that the "strict" option should be provided in *DateType* and *DateTimeType*.

Thanks.

---------------------------------------------------------------------------

by tanakahisateru at 2012-05-29T13:45:12Z

Simply, potentially some users can't find represented their own posts if "4" changed to "5" silently. I think, for regular users to understand why converted so is harder than to understand why blocked his date text.

---------------------------------------------------------------------------

by fabpot at 2012-05-30T05:19:44Z

I'm +1 for this change, but only on master. @bschussek?

---------------------------------------------------------------------------

by sstok at 2012-05-30T07:44:04Z

Date parsing with 'only' the Locale component is hard, especially the extra space or using / when only - is excepted.
And there also a locale that uses dd. mm. yyyy. (dot + space).

So to overcome this I have created a little helper class https://github.com/rollerworks/Locale.

It works as follow.
1. First it searches all the numeric-script characters, and converts those to ASCII decimals
2. Then matches the converted input against an pre-compiled regex that accepts extra spaces or using '/' instead of '-', and omitting leading zero's, etc...
3. Validate the matched parts using checkdate().

I'm not suggesting to only use my Component, but making an it an option would be something to consider, no?
Like an option mode: lenient/strict/match (match is the Rollerworks Locale Component or a-like).

The only thing currently missing is Timezone parsing support, but that is not to hard.
I only have not implemented this because there was no direct need for it at the time.

---------------------------------------------------------------------------

by bschussek at 2012-05-30T07:49:11Z

@fabpot Ok. In the long run we need to find a better solution anyway.
updated vendors for 2.0.15
updated CHANGELOG for 2.0.15
update CONTRIBUTORS for 2.0.15
updated VERSION for 2.0.15
bumped Symfony version to 2.0.16-DEV
Accept calling setLenient(false)
MethodNotImplementedException -> MethodArgumentValueNotImplementedException
Fixed typo in ConstraintValidatorFactoryInterface PHPDoc (2.0)
merged branch raulfraile/patch-3 (PR #4505)

Commits
-------

26d416f Fixed typo in ConstraintValidatorFactoryInterface PHPDoc (2.0)

Discussion
----------

Fixed typo in ConstraintValidatorFactoryInterface PHPDoc: Constrain => Constraint.

Bug fix: yes
 Feature addition: no
 Backwards compatibility break: no
 Symfony2 tests pass: yes

Fixed typo in ConstraintValidatorFactoryInterface PHPDoc: Constrain => Constraint.
Fixes #4503

---------------------------------------------------------------------------

by travisbot at 2012-06-06T15:30:53Z

This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1546330) (merged 26d416fe into 9a5e6c90).
merged branch beberlei/GH-4491 (PR #4493)

Commits
-------

4938080 MethodNotImplementedException -> MethodArgumentValueNotImplementedException
789fc14 Accept calling setLenient(false)

Discussion
----------

GH-4491 - Move patch from master to 2.0

A patch in PR-4469 fixed an issue with setLenient() and not having intl. This was only merged into master, although the original issue was created in the 2.0 branch. This PR cherry-picked the patches against 2.0 again.

---------------------------------------------------------------------------

by travisbot at 2012-06-06T15:29:19Z

This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1527145) (merged 49380804 into 9a5e6c90).

---------------------------------------------------------------------------

by kbond at 2012-06-06T17:42:40Z

fixes #4491
merged branch jakzal/yamlDoubleQuotesDumperFix (PR #4320)

Commits
-------

b631073 [Yaml] Fixed double quotes escaping in Dumper.

Discussion
----------

[Yaml] Fixed double quotes escaping in Dumper

Issue #4308 is caused by Dumper::escapeWithDoubleQuotes() which uses [str_replace()](http://php.net/str_replace).

From the php docs:

> Because str_replace() replaces left to right, it might replace a previously inserted value when doing multiple replacements.

We should be very careful in deciding about the order of elements in $escapees array. I'd really appreciate if someone reviewed my fix. Tests say I didn't break anything but I'm not sure what percentage of Yaml specification is covered by tests.

Bug fix: yes
Feature addition: no
Backwards compatibility break: not that I know
Symfony2 tests pass: [![Build Status](https://secure.travis-ci.org/jakzal/symfony.png?branch=yamlDoubleQuotesDumperFix)](http://travis-ci.org/jakzal/symfony)
Fixes the following tickets: #4308

---------------------------------------------------------------------------

by travisbot at 2012-05-18T08:53:51Z

This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1364279) (merged 5192722c into a04acc89).

---------------------------------------------------------------------------

by travisbot at 2012-05-18T23:19:49Z

This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1371539) (merged ecaa1aab into fc3c609b).

---------------------------------------------------------------------------

by dinamic at 2012-05-19T07:35:21Z

Something is really wrong with this method. You can see clearly that multiple characters would fail proper escaping.

Here's an example:
```
$value = '\\\\"some value\n \"some quoted string\" and \'some single quotes one\'"';
var_dump(Escaper::escapeWithDoubleQuotes($value));
string(72) ""\\\"some value\n \\some quoted string\\ and 'some single quotes one'\"""
```

To begin with the backslash - in the initial value you have 2 (escaped ones), that after escaping should result in 4, not in 1 (escaped). I guess this behavior has to be verified with the importer, but imho it does not seem right.

Does anyone know why this escaping wasn't done using a regular expression in first place?

---------------------------------------------------------------------------

by clemens-tolboom at 2012-05-19T10:18:58Z

Searching for https://duckduckgo.com/?q=what+is+\xc2\x85 the table on http://stackoverflow.com/questions/6609895/efficiently-replace-bad-characters is interesting enough to decide we need way more documentation on this file.

\xc2\x85 seems to be triple dot (ellipses)
\xe2\x80\xa9 seems to be paragraph separator see http://drupal.org/node/914360#comment-3468550
Authorization header should only be rebuild when Basic Auth scheme is used
changed getName() to name on all Reflection* object calls (fixes #4555, refs https://bugs.php.net/bug.php?id=61384)
merged branch mvrhov/1813_regression (PR #4551)

Commits
-------

5d88255 Authorization header should only be rebuild when Basic Auth scheme is used

Discussion
----------

[Regression fix] Authorization header should only be rebuild when Basic Auth scheme is used

Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: fixes regression introduced by #1813
Todo: N/A
License of the code: MIT

---------------------------------------------------------------------------

by travisbot at 2012-06-11T14:40:28Z

This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1592604) (merged cf5ee26a into 27100ba4).

---------------------------------------------------------------------------

by mvrhov at 2012-06-12T06:13:01Z

fixed

---------------------------------------------------------------------------

by travisbot at 2012-06-12T06:14:55Z

This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1598555) (merged 5d88255d into 27100ba4).