Jira should store all dates that contain years with 4 digits of precision, and not just 2 digits

Problem Definition

Jira in the default settings is only storing two digit precision for years. This is not always a problem, but in some cases this can lead to data issues.

For parsing with the abbreviated year pattern ("y" or "yy"), SimpleDateFormat must interpret the abbreviated year relative to some century. It does this by adjusting dates to be within 80 years before and 20 years after the time the SimpleDateFormat instance is created. For example, using a pattern of "MM/dd/yy" and a SimpleDateFormat instance created on Jan 1, 1997, the string "01/11/12" would be interpreted as Jan 11, 2012 while the string "05/04/64" would be interpreted as May 4, 1964.

http://java.sun.com/j2se/1.4.2/docs/api/java/text/SimpleDateFormat.html

Today Jira still ships with a default date format of only two digits for the precision of the year, such as MM/dd/yy.

Suggested Solution

We should really not be relying upon Java's interpretation of what year is intended. Instead we should be implementing a four digit value for the year by default. This would require us to change the defaults for In the System > General Configuration > Advanced settings:

1. jira.date.picker.java.format
2. jira.date.picker.javascript.format
3. jira.date.time.picker.java.format
4. jira.date.time.picker.javascript.format**

 But also in the Look and Feel settings for Date/Time Format:

1. Complete Date/Time Format
2. Day/Month/Year Format**

For the java values

• Change all the 'yy' values to 'yyyy'

For all javascript values

• Change the '%y' values to '%Y'

Why this is important

Many users can create items and dates of events well beyond a 100 year range.  This becomes a real and obvious problem when trying to store that date with only 2 digits.  Dates entered such as 1/1/41 can be very ambiguous as to which year is being referenced here.  Relying upon Java, today that is interpreted as 1941, but next year, that would be interpreted as 2041 (20 years from the current year).  The solution seems obvious to attempt to completely avoid the ambiguity here and instead store this data with 4 digits of precision.  This solution it won't impact existing users and can prevent customer frustration and bad data over this problem.

Workaround

Jira administrators can change these java values from yy to yyyy and javascript values from %y to %Y to make this change manually.