@tehhowch I'm not familiar with date validations. Can you post some examples how you use them? Maybe we can figure out how to mitigate the pain.

For reference the PR that introduced the changes: adopted-ember-addons/ember-validators#100

I saw that PR, yes. (I also noticed that the changes to make the tests work completely ignored the point and purpose of some of the tests, e.g. every test around 'now' was reimplemented without changing the name-i.e. purpose-of the test, e.g. https://github.com/rwwagner90/ember-validators/pull/100/files?diff=split&w=0#diff-1b3840443c6b8c137c8790bb3a5e573b85ea331871438650849e8abf7b073d5fR120-R134)

The primary use case my team runs into is a validator that is defined in an internal addon that uses 'now', e.g.

const endDateInFutureValidation = {
  onOrAfter: 'now',
  format: SOME_FORMAT,
  errorFormat: OTHER_FORMAT,
  messageKey: 'validations.end.date.in.past',
};
// ...
const Validations = buildValidations({
  // ... other validatons
  endDate: validator('date', {
    disabled: or('..conditions'),
    ...endDateInFutureValidation,
  }),
})

and the goal is that users can't schedule something that is in the past. The upstream PR replaces usage of 'now' with explicit calls to the current time (example), which has no guarantee in production code that it is still the current time when the validation is actually performed, especially if the user has a long session.

I agree that the tests around the date validations got messy and should be revisited. Also the docs need an update.

Something I run into doing the updates was the fact that it's possible to have getter as options.

So in your case

const endDateInFutureValidation = {
  get onOrAfter() { 
    return new Date();
  }, 
  format: SOME_FORMAT,
  errorFormat: OTHER_FORMAT,
  messageKey: 'validations.end.date.in.past',
};

should work.

That could indeed work, but as I was investigating, I determined that PR to ember-validators also broke the expectations on format - namely, that the input date should be in that format, and if not, a wrongDateFormat error should be raised.

To unblock my team's apps, we have just completely stopped using the 'date' validator shipped by this repo/ember-validators, because using it would have required changing how we do 'now', 'precision', and also required inserting another validator to handle required formats.

(There was also the issue that the upstream PR defaults all input parsing of dates to new Date(<string>), which is well-documented as something you should avoid due to the wide variety of implementation behaviors.)

@tehhowch Did you use an inline validator to replace the date validator? Would be great if we can document how people in the same situation can solve the problem...

I extended the existing date validator and provided a fixed validate method that still used moment internally.

I think what could make sense is to provide two peer/optional dependencies, one for luxon and one for moment, and use the test method to have the 'date' validator use whichever has also been installed rather than the busted ember-validator version.

@tehhowch do you mind sharing your solution here so others can use it?

I'll need to reimplement it blind, so no promises on when I'll have free time to do that.

I also think there is perhaps more value to the approach I mentioned before, where library-specific validators (one for luxon, one for moment, etc.) are implemented and conditionally used. That would require the consumers to configure the add-on.

(Possibly those validators / customization belong in ember-validators instead, and we run into the issue of not wanting to auto-install all date libraries.)