Override date format on DatePicker component

[v3gard]

trafficstars

Is your feature request related to a problem? Please describe.

Here in the civilized part of the world, we use date formats like dd/mm/yy. To avoid confusing users that prefers mm/dd/yy (i.e. those that doesn't follow the obviously preferred standard), we should consider providing a universally accepted solution to a problem like 03/08/24

Depending on where you are in the world, this could mean

• August 3rd 2024
• March 8th 2024

Describe the solution you'd like

1. A callback function that provides the selected date according to the ISO standard (e.g. yyyy-mm-dd / 2024-03-08, which allows me to fully customize the output value that is shown to the end user in the date picker.

2. An example in the Story Book (to make it obvious to developers on how to apply this).

Describe alternatives you've considered

Creating a local variant that exists in the app we're responsible for. This does not bring any community value though....

Additional context

[josharian]

This seems like a reasonable request. (It is a trimmed back version of #2, but trimmed back in all the right ways.)

Suggested approach:

• Add a -incremental flag, use it to enable this new behavior. Alternatively, add a -all flag to disable the behavior and have incremental on by default.
• If you can't find an existing type that matches the provided type, pretend it exists and has no methods. In particular, don't emit an error in this case.

There is some subtlety around pointer vs non-pointer receivers. Suppose you call impl with an interface containing methods A() and B(), and you provide T as the type, and *T already has a method B(). Should impl generate func (t T) B() { panic(...) }? If yes, then you'll get a method redeclared error: https://play.golang.org/p/fNIjtt-ISj. If not, T won't satisfy the interface, despite your explicit request that it do so: https://play.golang.org/p/8sp05N9zg-. Or should it return an error, which I try to avoid at all costs?

I'd lead towards the method redeclared approach, on the grounds that it is the most likely to make it obvious to the user what has gone wrong. Thoughts welcomed, though.

[DenLilleMand]

This is exactly what i need, i suppose it has not been implemented or anything? @marcosnils did you do some work on it, or no?

[timsolov]

implemented in PR#36 but I didn't add -incremental parameter to save compatibility with current IDE logic.