Creating issue with invalid date format will still create issue even though error is thrown

Summary

JIRA has a Date Picker custom field, which accepts values which are formatted as described in Administration >> System >> General Configuration >> Advanced Settings as the jira.date.picker.java.format. By default, the format that is defined in JIRA is as follows:

• jira.date.picker.java.format : d/MMM/yy
• jira.date.picker.javascript.format : %e/%b/%y

When a user attempts to create an issue which has a Date Picker custom field and enters a date in a format that is unrecognized, JIRA will throw an error and prevent the issue from being created:

Invalid date format. Please enter the date in the format "d/MMM/yy".

However, it is possible to reconfigure the date picker format to an alternate, desired format. Though the specifics are unknown, certain formats will cause JIRA to throw a different error, while still creating the issue. In these circumstances, users who incorrectly enter the format may unwittingly create multiple issues, while believing that the issues are not being created.

Such issues created in this fashion have the following problems:

• They are not indexed, and do not come up in issue navigator searches until later reindexes
• The will not have the Date Picker custom field properly set

Users will not realize that these issues were created until a reindex later on, where all of the erroneously created issues will spontaneously appear.

Environment

• JIRA 7.4.0
• MS SQL Server 2012

Steps to Reproduce

1. Start with a fresh or existing JIRA instance
2. Create a brand new project (Project Type does not matter)
3. Create a new custom field of type Date Picker (e.g. "Date of Birth") and associate it with all screens in this project
4. Navigate to Administration >> System >> General Configuration >> Advanced Settings
5. Adjust jira.date.picker.java.format to MM/dd/yyyy
6. Adjust jira.date.picker.javascript.format to %m/%d/%Y
7. Create an issue, setting the Date Picker field to a value which does not align with the provided format (i.e. 01/01/14)

Expected Results

JIRA should reject the issue creation with a warning that the supplied date format of 01/01/14 does not meet the expected format MM/dd/yyyy.

Actual Results

1. JIRA rejects the issue creation with a different warning:

We can't create this issue for you right now, it could be due to unsupported content you've entered into one or more of the issue fields. If this situation persists, contact your administrator as they'll be able to access more specific information in the log file.

2. The following error is thrown in the application logs:

2017-08-09 15:35:09,286 http-nio-8098-exec-19 ERROR kliou 935x880x1 1rhnhcp 0:0:0:0:0:0:0:1 /secure/QuickCreateIssue.jspa [c.a.j.bc.issue.DefaultIssueService] Error creating issue: 
com.atlassian.jira.exception.CreateException: org.ofbiz.core.entity.GenericEntityException: while inserting: [GenericEntity:CustomFieldValue][parentkey,null][customfield,10203][issue,10013][datevalue,0014-01-01 00:00:00.0][id,10037] (SQL Exception while setting value:  (Only dates between January 1, 1753 and December 31, 9999 are accepted.))

3. The issue is still created, though the issue is not indexed and cannot be searched for. You may still access the issue directly via it's URL, which can be determined by the last known Issue Key and incrementing it's value by 1 (i.e. if the last issue key in this project was PROJ-12345, PROJ-12346 would have been created by this attempt). Alternatively, the database may be queried in the jiraissue table for the issuekey with the ID specified in the SQLException above (10013).

Workaround

• Avoid modifying the format of the date picker in JIRA's Advanced Settings, and use the default format instead, which seems to have a better functioning handler for invalid values
• Use the widget to select your date picker value, rather than typing it in. This will avoid improper formatting
• For the above example specifically, adjust the format from MM/dd/yyyy to MM/dd/yy. This will accept values where only the last two digits of the year value is offered, but may lead to inconsistent results (testing results show that a year value of "37" will assume 1937, but a year value of "36" will assume 2036).