Je voudrais faire la différence entre les objets de date valides et non valides en JS, mais je n'ai pas réussi à comprendre comment:
var d = new Date("foo");
console.log(d.toString()); // affiche 'Date invalide'
console.log(typeof d); // affiche 'object'
console.log(d instanceof Date); // affiche 'true'
Des idées pour écrire une fonction isValidDate
?
- Ash recommande d'utiliser
Date.parse
pour analyser les chaînes de date, ce qui donne une façon autorisée de vérifier si la chaîne de date est valide. - Si possible, j'aimerais que mon API accepte une instance de Date et qu'il soit possible de vérifier/affirmer si elle est valide ou non. La solution de Borgar le fait, mais je dois la tester sur différents navigateurs. Je me demande aussi s'il n'y a pas une façon plus élégante de faire.
- Ash m'a fait réfléchir à ne pas faire accepter des instances de
Date
par mon API du tout, ce serait le plus facile à valider. - Borgar suggère de tester si c'est une instance de
Date
, puis de tester la valeur temporelle de laDate
. Si la date est invalide, la valeur temporelle estNaN
. J'ai vérifié avec ECMA-262 et ce comportement est dans la norme, ce que je recherche exactement.
1 votes
J'ai supprimé ma réponse originale car vérifier si NaN est une solution bien meilleure que de comparer à une chaîne "Invalid Date". Je vais devoir utiliser la solution isNaN moi-même.
0 votes
@orip, "avez-vous essayé de faire accepter un Date instance à mon API et de pouvoir vérifier/affirmer si elle est valide ou non" Avez-vous essayé : isNan(d.getTime())==true sur l'instance de date?
0 votes
@Ash, oui - c'est ce que Borgar a suggéré. J'ai recherché la définition des méthodes de Date selon l'ECMA-262, et getTime n'est pas garanti de renvoyer NaN. Les autres méthodes "get*", telles que getMonth, le sont.
0 votes
Désolé, ma faute - getTime retourne bien NaN (retourne "la valeur de temps", qui est NaN si la date est invalide)
20 votes
Vous pourriez supprimer l'instruction if en modifiant le corps de la fonction à:
return (Object.prototype.toString.call(d) === "[object Date]" && !isNaN(d.getTime()));
1 votes
@styfle - bien sûr, mais pourquoi?
0 votes
@orip Cela rend le code plus lisible. Plus il y a de ifs, de returns, de nots, etc, plus le code peut devenir confus. La même raison pour laquelle vous ne faites pas
if (!bool == false) return false;
3 votes
@styfle - je suppose que c'est une préférence de style: je trouve qu'il est plus clair de séparer la vérification du type de la logique d'égalité.
0 votes
Veuillez garder à l'esprit que
Date.parse
dépend de l'implémentation, voir stackoverflow.com/questions/3085937/…0 votes
Pourquoi var d = new Date("30/30/44"); isValidDate(d); retourne-t-il true?
0 votes
Cela n'a pas fonctionné dans IE8 - Veuillez voir ici stackoverflow.com/questions/13878515/…
0 votes
IE roule sur ses mois. Un mois de 30 est en fait vu comme 2 ans et 6 mois. Ainsi, 30/30/44 dans IE crée un objet de date du 30 juin 46. L'objet Date est valide donc il passe le test ci-dessus. (Il roule probablement sur ses jours également)
0 votes
Donc
Object.prototype.toString.call(obj) === "[object Date]" && !isNaN(obj)
gagne. Cool. Cependant, le test pour une instance de Date devrait être séparé du test de si elle contient une valeur de temps valide car ce sont des préoccupations distinctes.0 votes
Pourquoi n'est-ce pas adéquat :
return d.toString() !== 'Invalid Date'
? Je suppose que la valeur est définie dans la spécification et donc aussi fiable que les valeurs produites partypeof
.