I'm unclear why the new DateFormat function is needed at all - if the intent was to override validator then the formatting seems tangencial. If the source problem was the format then the solution may look different.

For clarity can you describe the original issue that this PR is resolving?

Thanks for the contribution :)

The original issue I had was that I couldn't clear the DateEntry without the default validator invalidating the field. This meant that I could not make an optional date input. I also have the need to check that the date is after a certain point in time. I can think of more examples, there are probably infinite use cases for custom date validation.

I was surprised when I couldn't just set the Validator field on the DateEntry and have that validator be used. Which is why I consider this to be a bug.

The user code needs to know which DateFormat the input is using, in order to parse the string which is passed to the Validator. The string needs to be parsed so that we can then run checks on the date which the user supplied.

Another solution to this could be ad a Validator kind of field that takes in a func(*time.Time) bool. But I thought that might be a bigger change, and doesn't fix the unexpected behaviour of a public field not having any effect.

The original issue I had was that I couldn't clear the DateEntry without the default validator invalidating the field.

Yup, let's get that fixed for sure.

I also have the need to check that the date is after a certain point in time

Isn't that possible with the builtin validator?

The user code needs to know which DateFormat the input is using, in order to parse the string which is passed to the Validator.

This is a side-effect of replacing the validator - if you call the builtin one it won't be required.

and doesn't fix the unexpected behaviour of a public field not having any effect.

Yes, that should be resolved as well - but you could chain your new validator on top of the old one...

It feels like I am missing something crucial in how to use the Validator.

Isn't that possible with the builtin validator?

Not in a way that I could figure out. As far as I know, the default Validator just checks whether it can parse the input to a date, and returns an error if it can't.

you could chain your new validator on top of the old one.

I am not sure about how I would go about achieving this. The old Validator is instantiated as part of CreateRenderer.
The only way I can think of doing that, is by validating the date in OnChanged and using SetValidationError. Is that the way I am meant to do it? Or am I missing something?

Isn't that possible with the builtin validator?

Not in a way that I could figure out. As far as I know, the default Validator just checks whether it can parse the input to a date, and returns an error if it can't.

Oh on reflection, I see you meant that you wanted to validate that the parsed date is after some date. I didn't get that before.
Given that won't you want to pass the default validator that handles parsing and then use the parsed time and do the comparison? Delegation should work nicely.

I am not sure about how I would go about achieving this. The old Validator is instantiated as part of CreateRenderer.

Fair, I missed that. You can call Refresh() first which will cause the renderer to be created. Not ideal but saves creating new APis.
Perhaps the cleaner solution is that we make a DateValidator - the toolkit can work out what the format would be from the locale without new public APIs on DateEntry...