Date inputs should respect users date format

[tqwewe]

Is your feature request related to a problem? Please describe. I struggled to finish the onboarding process since I was entering my birthdate as DD/MM/YYYY instead of the MM/DD/YYYY it was expecting. I also didn't receive any validation errors and was able to continue onto the next question in the form.

Describe the solution you'd like Date inputs should respect the users local format for dates. Some countries like the US have month first, and others such as Australia have the date first.

Additionally, the birthdate question in the on-boarding form should not let you continue if you've entered an invalid birthdate.

[tmyracle]

Here's my proposed solution:

• Move location question before birthday so we know what country the user is in (rather than trying to guess via IP or something)
• Add a field in geo-utils.ts for the date format for that country according to date format by country
• Add a prop to DatePicker component that takes in the date format and parses the date accordingly and sets an error message if the existing if (inputData.isValid) check fails.
• Update use of DatePicker in birthday question to use the selected country to return the appropriate date format from geo-utils.ts
• Update all other uses of DatePicker to use the country field on the User to set the appropriate format

[Shpigford]

@tmyracle Your solution sounds good.

[bhardwajakshit]

@Shpigford @tmyracle I'd be happy to take up this issue and contribute.

[ludvigrosenqvist]

@tmyracle Wouldn't a simpler solution be to use the standardized date format of ISO8601, YYYY-MM-DD? This skips having to take every locale date format into account. If needed, you can simply parse the date to US formatting like so:

const date = new Date('2019-04-12');
const usFormattedDate = date.toLocaleDateString('en-US')

[tmyracle]

@tmyracle Wouldn't a simpler solution be to use the standardized date format of ISO8601, YYYY-MM-DD? This skips having to take every locale date format into account. If needed, you can simply parse the date to US formatting like so:

const date = new Date('2019-04-12');

const usFormattedDate = date.toLocaleDateString('en-US')

the date is already parsed, this is more about having the UI reflect the convention for the users country

[ullasgowda]

__ Since toLocaleString() gives out date formatted with respect to the user's environment, usually the browser settings / system settings, maybe need to think if it is necessary to consider the country input from user and determine the date format.

Maybe it is a good choice to adapt to the system/browser settings for consumer applications, unless there is a specific reason to do so.

For example, if a user is using the app across multiple regions on different days (where there is a difference with date format) and there is a need to keep format consistent across, then it would be a good choice to do it.

In most cases, maybe the default system / browser settings does the trick.

DateTime.now().toLocaleString(DateTime.DATE_SHORT)

Let me know what do you think ?

[Shpigford]

@ullasgowda We need to ask for the user's country regardless as it lets us focus certain in-app prompts (like data connectors) based on that location. It essentially lets us make bigger, long-term UI/UX decisions about their account vs us just "assuming" based on their current browser.

[tqwewe]

I also want to highlight this point, since I haven't seen it mentioned here.

Additionally, the birthdate question in the on-boarding form should not let you continue if you've entered an invalid birthdate.

I went through the process thinking that my birthdate was correct because it let me continue without any red errors. Other sections dont let you progress unless its valid, so this was very confusing.

[tmyracle]

I also want to highlight this point, since I haven't seen it mentioned here.

Additionally, the birthdate question in the on-boarding form should not let you continue if you've entered an invalid birthdate.

I went through the process thinking that my birthdate was correct because it let me continue without any red errors. Other sections dont let you progress unless its valid, so this was very confusing.

Interesting, there's validation on that field so it definitely should have caught it. Can you give me an example of a date that isn't valid, but allows you to proceed? Also what browser are you using?

[tqwewe]

I'm using firefox, and the date was 22/03/2000 @tmyracle

[domabyte]

I'm using firefox, and the date was 22/03/2000 @tmyracle

No, it's still caught the invalid date