Bug of the week: date field only broken for Japanese users (and it was not timezone)

Hello everyone, first post here 🐞. I am QA in Hanoi, we test web app for one Japanese client and one Australian client. This week I found a bug that is so funny I want to share.

Symptom: Japanese client say "birthday field always say Invalid date". Australian client no problem. Dev team test it, no problem. Of course "cannot reproduce" 😅

First everybody think timezone, because it is always timezone. Not timezone. Then we think date format (Japan use YYYY/MM/DD, Australia use DD/MM/YYYY). Also not this, the field already handle both.

So I ask client for screen recording. In the video I see they type with Japanese IME still on, because they type their name in Japanese just before. And with IME on, the numbers they type are full-width: １９９０／０６／０５, not 1990/06/05. On screen they look almost same, but they are different characters (U+FF10 to U+FF19 for the digits, and the slash is also different).

Our validation was:

const DATE_RE = /^(\d{4})\/(\d{1,2})\/(\d{1,2})$/
if (!DATE_RE.test(value)) return 'Invalid date'

In JavaScript \d match only ASCII 0-9. So full-width digits always fail. The bug is appear only when user type numbers with IME on, which is every Japanese user who type the name first 😅

Fix (dev do it, I only find it, but I am very proud):

const normalized = value.normalize('NFKC').trim()
if (!DATE_RE.test(normalized)) return 'Invalid date'

NFKC change full-width digits and full-width slash to the normal ASCII ones. We also apply it to phone number and postal code field, same problem was there.

Lesson for me: when only users from one country have the bug, ask for a video, not only steps. The steps said "type 1990/06/05". The steps were correct. The characters were not.

Now I add test case with full-width input for every number field. Dev team look at me like I am villain again 🐞