flag for @IsDateString() to validate date without time
It`s more feature request. I think it would be nice to have ability validate date string without time using @IsDateString() decorator. For example, '2000-07-26', not '2000-07-26T00:00:01.967Z'. Cannot find how to do that not using @Matches() decorator.
Feel free to contribute :)
I agree. There should be two different functions one for checking isostring and another for plain date string
@vlapo i am taking this one
I create custom one.
import { registerDecorator, ValidationOptions } from 'class-validator';
export function IsOnlyDate(validationOptions?: ValidationOptions) {
return function(object: Object, propertyName: string) {
registerDecorator({
name: 'IsOnlyDate',
target: object.constructor,
propertyName: propertyName,
constraints: [],
options: {
message: 'Please provide only date like 2020-12-08',
...validationOptions,
},
validator: {
validate(value: any) {
const regex = /([12]\d{3}-(0[1-9]|1[0-2])-(0[1-9]|[12]\d|3[01]))/;
return typeof value === 'string' && regex.test(value);
},
},
});
};
}
@jerryfreshworks as a little note - the provided validator passes 2020-02-31 as a correct date so it's rather a format validator than actually validating if the date exists.
anything ?
for date format only you can use Matches validator
@Matches(/^\d{4}(-)(((0)[0-9])|((1)[0-2]))(-)([0-2][0-9]|(3)[0-1])$/i, {
message: "$property must be formatted as yyyy-mm-dd"
})
@talski of course we can use regular expressions.. basically we can use them for all validations, but I think the point of the creation of this library was to simplify this process
2000-07-26
so correct me if i am wrong but it should also validate the date string as valid / invalid date after validating the format?
@talski of course we can use regular expressions.. basically we can use them for all validations, but I think the point of the creation of this library was to simplify this process
yes, we can use regex for almost all the validations provided by library but people are looking for out of the box solutions like you said
import { ValidatorConstraint, ValidatorConstraintInterface } from 'class-validator';
import moment = require('moment');
@ValidatorConstraint()
export class isDate implements ValidatorConstraintInterface {
validate(value: any) {
if (typeof value === 'string') {
return /^[1-9]\d*-(0[1-9]|1[0-2])-(0[1-9]|[12]\d|3[01])$/.test(value) && moment(value, 'YYYY-MM-DD').isValid();
}
return false;
}
defaultMessage({ property }) {
return `${property} must be a valid date (Required format: YYYY-MM-DD)`;
}
}
Hope this helps!
@IsISO8601 does the job!
@pasan9, thanks my friend, you saved my day.
@IsISO8601 does the job!
Yes, but how to ensure we only receive a date (without time)? Currently, I do this:
@IsISO8601({ strict: true })
@Length(10, 10)
but I am wondering if there is something cleaner to do. Is there any option to the @IsISO8601() decorator I can use to specify I only accept a date?
The best answer I found for this issue on stack overflow: https://stackoverflow.com/a/62517465/3342886
There is an ongoing PR in validator.js where ISO8601 is being discussed in terms of what subsets of ISO 8601 should be most prominent (conigurable via options flags). ISO 8601 is notoriously all inclusive, allowing things that may not seem correct at first glance such as ordinal dates without a separator: 1933329
If you have an opinion about which date/date time formats are most important/relevant, feel free to chime in.
This is currently possible. The @IsDateString can validate only YYYY-MM-DD pattern, and with a @MaxLenght decorator you can enforce that no time part is specified.
import { IsDateString, MaxLength, validate } from 'class-validator';
class MyPayload {
@MaxLength(10)
@IsDateString()
date: string;
constructor(date?: string) {
this.date = date;
}
}
// Will pass
validate(new MyPayload('2022-12-24')).then(console.log);
// Will fail
validate(new MyPayload('2022-12-24:12:00:00Z')).then(console.log);
validate(new MyPayload('invalid')).then(console.log);
It's always a good idea to think of decorators as pieces of Lego. Some things can only be achieved with multiple decorators. The solution is not always to extend the decorator we first thought of using to match my exact use-case.
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.