Steps to Reproduce:

1. Go to Administration > General Configuration > Advanced.
2. Change the jira.date.picker.java.format from d/MMM/yy to dd/MM/yyyy.
3. Create or edit an issue and type a number date in the Due Date field with format d/m/yy such as 1/1/14 for example
4. Then click create or edit.
5. After it is created or updated, go to the issue and click edit.

Expected Results:

It will give that the format entered is wrong or the date typed in the field 1/1/14 it will 01/01/2014 stored in the field.

Actual Results:

The date typed is accepted and the Due Date field is storing 01/01/0014 instead of 2014.

Notes:

• Usually, if it is for month such as MMM it will throws error if number is typed instead of the month name, looks like there is not any warning for year.
• This affect the Date Picker Custom Field.
• The Date will still showing the correct date such as 1/1/14 become 1/Jan/14 on the Issue View, since this is directing to the Date/Time format of Look and Feel
• It appears that it stores 0014 also in the database.
• Changing the Javascript format is not giving the correct value
• When using Jira with SQL Server, the following error will be thrown in the logs, due to the fact that MS SQL does not accept years lower than 1753:

  Error creating issue: 
  com.atlassian.jira.exception.CreateException: org.ofbiz.core.entity.GenericEntityException: while inserting: [GenericEntity:CustomFieldValue][parentkey,null][customfield,11000][issue,38000][datevalue,0014-01-01 00:00:00.0][id,370000][updated,1567600000] (SQL Exception while executing the following:INSERT INTO jiraschema.customfieldvalue (ID, ISSUE, CUSTOMFIELD, UPDATED, PARENTKEY, STRINGVALUE, NUMBERVALUE, TEXTVALUE, DATEVALUE, VALUETYPE) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?) (The conversion of a datetime2 data type to a datetime data type resulted in an out-of-range value..))
  	at com.atlassian.jira.issue.managers.DefaultIssueManager.createIssue(DefaultIssueManager.java:600)
  	at com.atlassian.jira.issue.managers.DefaultIssueManager.createIssue(DefaultIssueManager.java:501)
  	at com.atlassian.jira.issue.managers.RequestCachingIssueManager.createIssue(RequestCachingIssueManager.java:193)
  

Additional investigation
After doing some more checking, this actually appears to be expected behaviour:

For parsing, if the number of pattern letters is more than 2, the year is interpreted literally, regardless of the number of digits. So using the pattern "MM/dd/yyyy", "01/11/12" parses to Jan 11, 12 A.D.

source:
http://docs.oracle.com/javase/6/docs/api/index.html?java/text/SimpleDateFormat.html

A proper way to prevent this from happening can be found here:
https://answers.atlassian.com/questions/118070/date-format-issue-year-accepts-2-digits-and-saves-incorrect-date