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.
This commit is contained in:
Farhaan Bukhsh 2019-10-11 23:33:29 +07:00 committed by Mariusz Felisiak
parent 550357771b
commit cf5d4701dc
4 changed files with 20 additions and 1 deletions

View File

@ -285,6 +285,7 @@ answer newbie questions, and generally made Django that much better:
Eugene Lazutkin <http://lazutkin.com/blog/> Eugene Lazutkin <http://lazutkin.com/blog/>
Evan Grim <https://github.com/egrim> Evan Grim <https://github.com/egrim>
Fabrice Aneche <akh@nobugware.com> Fabrice Aneche <akh@nobugware.com>
Farhaan Bukhsh <farhaan.bukhsh@gmail.com>
favo@exoweb.net favo@exoweb.net
fdr <drfarina@gmail.com> fdr <drfarina@gmail.com>
Federico Capoano <nemesis@ninux.org> Federico Capoano <nemesis@ninux.org>

View File

@ -159,7 +159,14 @@ function findPosY(obj) {
year = date[i]; year = date[i];
break; break;
case "%y": case "%y":
// 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]; year = date[i];
} else {
year = (new Date(Date.UTC(date[i], 0))).getUTCFullYear() + 100;
}
break; break;
} }
++i; ++i;

View File

@ -391,6 +391,10 @@ Miscellaneous
options on models in ``django.contrib`` modules that were formerly tuples are options on models in ``django.contrib`` modules that were formerly tuples are
now lists. 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: .. _deprecated-features-3.1:
Features deprecated in 3.1 Features deprecated in 3.1

View File

@ -55,6 +55,7 @@ QUnit.test('String.strptime', function(assert) {
assert.equal(firstParsedDate.getUTCMonth(), 1); assert.equal(firstParsedDate.getUTCMonth(), 1);
assert.equal(firstParsedDate.getUTCFullYear(), 1988); 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'); var secondParsedDate = '26/02/88'.strptime('%d/%m/%y');
assert.equal(secondParsedDate.getUTCDate(), 26); assert.equal(secondParsedDate.getUTCDate(), 26);
assert.equal(secondParsedDate.getUTCMonth(), 1); assert.equal(secondParsedDate.getUTCMonth(), 1);
@ -67,6 +68,12 @@ QUnit.test('String.strptime', function(assert) {
assert.equal(thirdParsedDate.getUTCMonth(), 10); assert.equal(thirdParsedDate.getUTCMonth(), 10);
assert.equal(thirdParsedDate.getUTCFullYear(), 1983); 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 // Extracting from a Date object with local time must give the correct
// result. Without proper conversion, timezones from GMT+0100 to GMT+1200 // result. Without proper conversion, timezones from GMT+0100 to GMT+1200
// gives a date one day earlier than necessary, e.g. converting local time // gives a date one day earlier than necessary, e.g. converting local time