[12.0.0+] Incorrect date format conversion on input

[adrianszymanski89]

Description

When we have dateFromat set to MM/DD/YY and we input, for example - 7/1/22 in the cell, it is incorrectly converted to 01/07/2022. It used to be converted correctly in Handsontable v. 11.1.0 (before updating moment.js dependency #9381)

Steps to reproduce

1. Type 7/1/22 in the date cell;
2. Press enter;

Demo

V 11.1.0 (works correctly) - https://jsfiddle.net/aszymanski/nqv3btc0/1/
V 12.0.0 (and higher, it's broken) - https://jsfiddle.net/aszymanski/nqv3btc0/2/

Your environment

• Handsontable version: 12.0.0+
• Browser name and version: Google Chrome 103
• Operating system: macOS Monterey 12.4

[adrianszymanski89]

Inform ZD (29687)

[aninde]

Another example for this case
date format: 'YYYY-MM-DD'
Typing 10-11-12, I expected 2010-11-12, but the result is inverted to 2012-11-10.

Screen.Recording.2022-07-18.at.15.59.33.mov

[wszymanski]

What is the goal? If you want only one digit of the date to be displayed (if you are dealing with a single digit number) please use appropriate M/D/YYYY format. Please let me know if that's what you mean.

edit: Okey, it's probably about correctFormat. Please provide information about it in the issue description and additionally show an expected result.

I've checked the code and it seems that:

a) default dateFormat also hasn't been changed.
b) used correctFormat method hasn't been changed.

handsontable/src/validators/dateValidator.js

Lines 46 to 62 in f4c2ca0

	/**
	* Format the given string using moment.js' format feature
	*
	* @param {String} value
	* @param {String} dateFormat
	* @returns {String}
	*/
	let correctFormat = function correctFormat(value, dateFormat) {
	let date = moment(new Date(value));
	// Ugly fix for moment bug which can not format 5-digits year using YYYY
	if (date.format('YYYY').length > 4) {
	date.year((date.year() + '').substr(0, 4));
	}
	return date.format(dateFormat);
	};

Upgraded moment.js may have bug or library API has changed. We upgraded from 2.24.0 to 2.29.3 (12.0.0 release) within #9382 and from 2.29.3 to 2.29.4 (12.1.2 release) within #9637.

[warpech]

Okey, it's probably about correctFormat. Please provide information about it in the issue description and additionally show an expected result.

I don't think so. I can see the same problem without correctFormat:

• 11.1 https://jsfiddle.net/warpech/wa58goL2/1/
• 12.0 https://jsfiddle.net/warpech/xjrf0y1p/1/

I think the problem is that Pikaday transforms the input before closing the editor. On this line, Pikaday chooses defaultDateFormat:

handsontable/handsontable/src/editors/dateEditor/dateEditor.js

Line 242 in 6a17060

options.format = options.format || this.defaultDateFormat;

Why is this a problem starting from 12.0, I don't know. Maybe something has changed in the editor closing code.

[wszymanski]

Okey, it's probably about correctFormat. Please provide information about it in the issue description and additionally show an expected result.

I don't think so. I can see the same problem without correctFormat:

• 11.1 jsfiddle.net/warpech/wa58goL2/1
• 12.0 jsfiddle.net/warpech/xjrf0y1p/1

I think the problem is that Pikaday transforms the input before closing the editor. On this line, Pikaday chooses defaultDateFormat:

handsontable/handsontable/src/editors/dateEditor/dateEditor.js

Line 242 in 6a17060

options.format = options.format || this.defaultDateFormat;

Why is this a problem starting from 12.0, I don't know. Maybe something has changed in the editor closing code.

I'll check that.

[wszymanski]

Okey, it's probably about correctFormat. Please provide information about it in the issue description and additionally show an expected result.

I don't think so. I can see the same problem without correctFormat:

True.

I think the problem is that Pikaday transforms the input before closing the editor.

The below Pikaday's code changes how date look like after closing the editor. Maybe it's related to introducing ShortcutManager. Maybe some event isn't prevented. I'll check that yet.

https://github.com/Pikaday/Pikaday/blob/21f676e70d688d18b265f2c12fc38e8457c20645/pikaday.js#L595

[wszymanski]

I confirm that after checking develop branch I can see that c06c32b introduce changes which affects in entering to mentioned above part of the code. On the previous e8e3a9f commit Pikaday's setDate method isn't called.

[wszymanski]

@adrianszymanski89 @warpech I've created a workaround, but I assume that fix should be provided in a different place. It corrects incorrect behavior of using Pikaday's method, not the cause of the problem.

Workaround: https://jsfiddle.net/pqn910ju/

[wszymanski]

It seems that there are two bugs:

1. The value inside the cell is changed right after pressing ENTER key (from 01/07/2022 to 07/01/2022).

Sep-06-2022.17-16-38.mp4

2. The value shown in the widget is wrong (it shows 7th of January 2022 instead of 1st of July 2022).

The first problem has been fixed by commit: 824ab4e. The window object is capturing an event later that document.documentElement (it occurs as next in the hierarchy). That's why Pikaday has been catching the change event as first (before keydown event). This leads us to some problems.

The second problem is investigated. Pikaday uses moment internally and call toDate method which doesn't work as I assume (please see the below example).

const momentDate = moment('01/07/2022', 'MM/DD/YYYY');
momentDate.toDate(); // Fri Jan 07 2022 00:00:00 GMT+0100 (Central European Standard Time)

edit: It seems that method works properly.

[wszymanski]

I've found extra problem related to flickering while entering data by copy+paste and enter key.

flickering.mp4

I'll restore mechanism which has been working up to version 12.0.0 (an extra event.stopPropagation blocked event captured by Pikaday).

[budnix]

@wszymanski, I believe you closed the issue by accident 😄 The issue should be closed by the support team after the fix is released and confirmed that it works.

[wszymanski]

@wszymanski, I believe you closed the issue by accident 😄 The issue should be closed by the support team after the fix is released and confirmed that it works.

Sure, thanks. It has been closed automatically, after merging the PR. It probably happened after using the word "fixed".

[aninde]

This issue will be fixed by v12.1.3

[AMBudnik]

Issue closed as fixed in Handsontable v12.1.3