I suppose Min / MaxValueValidator cannot be reused here because they expect a
fixed bound, while past / future depends on the current date?
The implementation Mariano provided looks simple enough to reproduce and adapt
to each project’s requirements (even though I’d prefer duck typing to type
Jani is correct, you'll need to be careful to handle timezones if timezones
are activated in SETTINGS. I can see value in a django-validators external
package that you could expand upon with newer validators as they come up.
But whether or not you want to build and maintain such a project is
Hi,
As Tim pointed out this can easily live as an external package.
Also you have to be really careful with dates and specially datetimes
when playing with timezones and daylight saving time. Specially since
you mention that invoice dates that may belong to past/present/future.
On
Actually I remember you can use field__lt to compare with a datetime object
(e.g. datetime.now()) and validate it.
Best regards,
Ares Ou
*Software Engineer / Full-Stack Python Developer | **Phone:* (510) 328 -
5968
*Blog:* http://aresou.net | *Github:* https://github.com/aresowj |
Thanks for the proposal. MaxValueValidator and MaxValueValidator are
included because they're needed for IntegerField validation. I don't think
the proposed validators meet the criteria of "needed in 80% of Django
projects" or "can't easily be implemented as a third-party app".
On Tuesday,
Hello django-developers@,
On more than one project, I find myself implementing the same feature over
and over again. It's not a rare case scenario, for instance: it's common
that invoices have a date that belongs to the past or the present time, but
not the future.
Seeing that we have
