Date of birth handling is wrong

[RKlingler]

Extension version

1.8.1

Short problem description

Date of birth validation is insufficient and/or date is stored in the wrong format.

Steps to reproduce

1. Register for an event using the date of birth: "1.1.90" (German date format)
2. Check date of birth in new registration notification mail
3. Compare date of birth in confirm registration notification mail

Expected behavior

The validation should either determine this to be invalid, as the given year only consists of two ciphers, or it should be interpreted as "01.01.1990". The date of birth should then be consistent in all notification mails.

Actual behavior

In the new registration mail, the date is shown as "01.01.0090".
In the confrm registration mail, the date is shown as "13.12.1901".

The extension interprets the input as "01.01.90" - as in January 1st year 90. In the database the date of birth is stored as a Unix timestamp in an integer column. The given date however goes out of bounds regarding the integer range, thus resulting in the lowest possible value, which is -2147483648 (= 13.12.1901).

This is basically a combination of a technical issue and a usability issue:

1. The date of birth should be stored as a date instead of an integer value.
2. The date validation should either convert "1.1.90" to "01.01.1990" or mark the input as invalid.

Server configuration

TYPO3 version:
6.2.x

PHP version:
5.6.8

[derhansen]

This problem is related to the Extbase DateTimeConverter in TYPO3, which is responsible for the conversion of the date string. From a technical point of view, the DateTimeConverter converts a datestring as following \DateTime::createFromFormat($dateFormat, $dateAsString);.

Sadly, the DateTimeConverter for the dateOfBirth field is always called before the Extbase datefield validation. Therefore, Extbase will always receive a valid date field, if the DateTimeConverter can convert the datestring.

As far as I found out, there is no "good" possibility to validate the entered date format, before the DateTimeConverter converts the field input. The only possibility is to extend the DateTimeConverter, which will result in a TYPO3 systemwide extension of the DateTimeConverter. This may lead to other unexpected behaviour in TYPO3 :-(

I was about to write a blog article about this topic, but due to missing time, this is on hold.

Therefore I suggest to use client side date validation and/or a JS datepicker for the dateOfBirth field.

I'll keep this issue open, so I can have a deeper look into the issue.

[tmotyl]

There is another issue with the date currently.

• date filed is decalred as default '0' NOT NULL which stands for 1.1.1970
• date field is not mandatory, but when you leave it not filled in backedn, on save you will get error "
  2: SQL error: 'Incorrect integer value: '' for column 'date_of_birth' at row 1' (tx_sfeventmgt_domain_model_registration:NEW596a935ccfaf5039352583)"
  when using mysql strict mode.

[derhansen]

@tmotyl I created a fix f599437 for the problem with MySQL running in strict mode. Does this resolve your problem?

[derhansen]

Closing the issue for now.