Fixed #30819 -- Fixed year determination in admin calendar widget for two-digit years.

Two-digit years in the range of [00, 68] are in the current century,
while [69,99] are in the previous century, according to the Open Group
Specification.

4 files changed, 20 insertions, 1 deletions

diff --git a/AUTHORS b/AUTHORS
index 6ef04af838..8b4492cc5c 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -285,6 +285,7 @@ answer newbie questions, and generally made Django that much better:
     Eugene Lazutkin <http://lazutkin.com/blog/>
     Evan Grim <https://github.com/egrim>
     Fabrice Aneche <akh@nobugware.com>
+    Farhaan Bukhsh <farhaan.bukhsh@gmail.com>
     favo@exoweb.net
     fdr <drfarina@gmail.com>
     Federico Capoano <nemesis@ninux.org>
diff --git a/django/contrib/admin/static/admin/js/core.js b/django/contrib/admin/static/admin/js/core.js
index e3ca0b6e57..a90d185d7a 100644
--- a/django/contrib/admin/static/admin/js/core.js
+++ b/django/contrib/admin/static/admin/js/core.js
@@ -159,7 +159,14 @@ function findPosY(obj) {
                 year = date[i];
                 break;
             case "%y":
-                year = date[i];
+                // A %y value in the range of [00, 68] is in the current
+                // century, while [69, 99] is in the previous century,
+                // according to the Open Group Specification.
+                if (parseInt(date[i], 10) >= 69) {
+                    year = date[i];
+                } else {
+                    year = (new Date(Date.UTC(date[i], 0))).getUTCFullYear() + 100;
+                }
                 break;
             }
             ++i;
diff --git a/docs/releases/3.1.txt b/docs/releases/3.1.txt
index 16d475b45b..51a0c69ac6 100644
--- a/docs/releases/3.1.txt
+++ b/docs/releases/3.1.txt
@@ -391,6 +391,10 @@ Miscellaneous
   options on models in ``django.contrib`` modules that were formerly tuples are
   now lists.
 
+* The admin calendar widget now handles two-digit years according to the Open
+  Group Specification, i.e. values between 69 and 99 are mapped to the previous
+  century, and values between 0 and 68 are mapped to the current century.
+
 .. _deprecated-features-3.1:
 
 Features deprecated in 3.1
diff --git a/js_tests/admin/core.test.js b/js_tests/admin/core.test.js
index 8904e5ad9f..9e1f3fa9b6 100644
--- a/js_tests/admin/core.test.js
+++ b/js_tests/admin/core.test.js
@@ -55,6 +55,7 @@ QUnit.test('String.strptime', function(assert) {
     assert.equal(firstParsedDate.getUTCMonth(), 1);
     assert.equal(firstParsedDate.getUTCFullYear(), 1988);
 
+    // A %y value in the range of [69, 99] is in the previous century.
     var secondParsedDate = '26/02/88'.strptime('%d/%m/%y');
     assert.equal(secondParsedDate.getUTCDate(), 26);
     assert.equal(secondParsedDate.getUTCMonth(), 1);
@@ -67,6 +68,12 @@ QUnit.test('String.strptime', function(assert) {
     assert.equal(thirdParsedDate.getUTCMonth(), 10);
     assert.equal(thirdParsedDate.getUTCFullYear(), 1983);
 
+    // A %y value in the range of [00, 68] is in the current century.
+    var fourthParsedDate = '27/09/68'.strptime('%d/%m/%y');
+    assert.equal(fourthParsedDate.getUTCDate(), 27);
+    assert.equal(fourthParsedDate.getUTCMonth(), 8);
+    assert.equal(fourthParsedDate.getUTCFullYear(), 2068);
+
     // Extracting from a Date object with local time must give the correct
     // result. Without proper conversion, timezones from GMT+0100 to GMT+1200
     // gives a date one day earlier than necessary, e.g. converting local time