Issues with Date Internationalisation

[DougMidgley]

When setting locale ambiguous dates such as 8/6/2018 which could be 6th August (US format) or 8th June (International Format) the date parser can sometimes mistakenly reset date to the other format.
This is set in date-picker.jsx in the Formatter (line 186 I think) where the date is set which is currently in International DD/MM/YYYY format, but when parsing using the default parser (218) it reads this in MM/DD/YYYY format, thus changing the date.
Would it make sense to use YYYY-MM-DD format in the Formatter to avoid such potential issues?

[interactivellama]

I would recommend not using the built in date parser date() and use something better like MomentJS via the parser callback.

parser: Custom function to parse date string into and return a Date object. Default function passes the input value to Date() and prays for a miracle. Use an external library such as MomentJS if additional date parsing is needed.

Should this suggestion be mentioned higher in in the Datepicker doc page? https://react.lightningdesignsystem.com/components/datepickers/

[interactivellama]

@DougMidgley Does MomentJS as the date parser fix the issue? Is there a way I can make this more clear?

Would a console warning about not using the built-in date parser help? I would like to limit hard dependencies, but also not promote the default.

[DougMidgley]

@interactivellama I can understand the desire to avoid dependencies, but surely, the default option should at least work? using a YYYY-MM-DD format will always parse the same so would be good to use as the default. Then any different formats can always use MomentJS

[interactivellama]

OK, got it. The issue is that calling dateString/Data.parse on the US format doesn't parse correctly.

Since the docs say always use something like MomentJS, the default can probably be more easily changed without side effects. Let's change the formatter to be be 8601 which will most likely force devs to use something else or at least write their own function.

This tricky part is that changing defaults could mess up some UIs. I'm thinking we could do this if we checked the parse function for the original US format and threw a warning since Date() shouldn't take the US formatting anyway and it would warn devs to change their code. What do you think of that proposal? Are you able to contribute it?

In the concrete, we'd check to see if the string is in US format and if it is fire off a console warning in our default parser to tell folks not to use the default parser.