Moment: Contrôle sur l'exclusivité/le comportement d'exclusivité d'isBetween

J'aimerais aussi ça.

Je suis d'accord, ce serait une fonctionnalité utile incroyable. Pouvoir choisir entre isBetween inclusif et exclusif, ou passer l'inclusion comme argument booléen serait fantastique.

Il y a en fait un peu plus de réflexion qui doit entrer dans cette fonction que ce qui est actuellement offert ou ce qui est proposé.

Dans les scénarios du monde réel, la valeur de départ est toujours inclusive, mais la valeur de fin est soit inclusive, soit exclusive _selon la granularité_. Plus précisément, si la valeur comprend une composante temporelle, la valeur de fin doit être exclusive. S'il n'inclut pas de composant de temps, alors il doit être _inclus_.

Pensez-y de cette façon. Si je vous demande combien de jours il y a entre le 1er et le 3 janvier, la réponse est trois jours . Mais si je vous demande combien d'heures il y a entre 13h00 et 15h00, la réponse est deux heures . Les humains le font naturellement. Cela a un impact sur la façon dont nous mesurons les durées entre les intervalles (comme avec moment#diff ) et comment nous testons une valeur pour voir si elle est dans la plage (comme avec moment#inBetween ).

Le comportement actuel de moment#isBetween est totalement exclusif, quelle que soit la granularité. Ce n'est pas très utile.

Le comportement actuel de moment#diff est inclusif au début et exclusif à la fin, encore une fois, quelle que soit la granularité. Ceci est valable pour le temps, bug invalide pour des jours. En effet, l'exemple dans la doc est :

var a = moment([2007, 0, 29]);
var b = moment([2007, 0, 28]);
a.diff(b, 'days') // 1

Alors qu'en réalité, la plupart des gens s'attendraient à ce que le résultat soit de 2 jours.

Le problème ultime est qu'un objet moment est une unité de temps discrète, mais dans de nombreux cas, nous essayons de le traiter comme une date sur un calendrier, et c'est là que les effets secondaires commencent à devenir visibles.

Pensez-y de cette façon. Si je vous demande combien de jours il y a entre le 1er et le 3 janvier, la réponse est trois jours. Mais si je vous demande combien d'heures il y a entre 13h00 et 15h00, la réponse est deux heures.

Je pense que la réponse logique (et pour moi, attendue) est "2" lorsque l'on demande à une bibliothèque de dates le nombre de jours entre "1er janvier" et "3 janvier". La raison étant que sans heure spécifiée, je m'attendrais à ce que cela fonctionne entre le "1er janvier 00h00" et le "3 janvier 00h00". La façon dont les humains font la différence dans le monde réel dépend vraiment du contexte, mais je ne pense pas que cela ait quoi que ce soit à voir avec la façon dont les choses fonctionnent dans le monde de la programmation.

Voici comment c'est fait pour PHP's Carbon et je n'ai jamais trouvé que cela soit un problème : https://github.com/briannesbitt/Carbon/blob/master/src/Carbon/Carbon.php#L1070 -1092

La seconde où nous avons fusionné isBetween Je savais que certaines personnes voudront spécifier un comportement différent pour les intervalles, mais je n'ai pas encore vu de bonne proposition. En fin de compte, les deux extrémités seraient configurables séparément (qu'elles soient inclusives/exclusives).

Il doit également être rétrocompatible avec la version actuelle.

// proposal 1
m.isBetween(a, b, "()"); // both excluded
m.isBetween(a, b, "[)"); // start included, end excluded

// proposal 2
m.isBetween(a, b, "+"); // both included
m.isBetween(a, b, "+-"); // start included, end excluded

Je ne peux pas penser à un scénario du monde réel pour exclure le début, il pourrait donc s'agir simplement d'un indicateur booléen pour exclure ou non la fin.

Bien que - j'aime un peu la proposition 1, car elle est proche de la notation d'intervalle ISO 31-11 appropriée

// these are essential
m.isBetween(a, b, "[]"); // both included
m.isBetween(a, b, "[)"); // start included, end excluded

// these would be rarely used, but complete the syntax
m.isBetween(a, b, "()"); // both excluded
m.isBetween(a, b, "(]"); // start excluded, end included

Je n'aime pas vraiment la proposition 2. (sans vouloir offenser)

:+1: pour la première proposition.

Honnêtement, je ne vois aucun scénario dans lequel vous voudriez explicitement exclure l'une ou l'autre extrémité mais pas les deux. Même si vous essayez de voir "jusqu'à ce jour", vous pouvez utiliser moment( date ).endOf( "day" ) comme date de fin, ce qui vous donnerait 23:59.59.

Je pense qu'il devrait juste y avoir un indicateur booléen pour le rendre inclusif/exclusif, tout comme une plage "normale" dans la plupart des langages de programmation. Restez simple pour éviter toute confusion - si vous voulez une heure _juste avant_ une heure de fin, il existe d'autres moyens de l'obtenir.

@mckinnsb - Cette approche est généralement évitée pour deux raisons :

1. La précision devient importante. En JavaScript, la dernière heure possible d'une journée standard serait 23:59:59.999 , mais dans d'autres langages, cela pourrait être 23:59:59 , ou 23:59:59.9999999 . Nous interagissons avec les valeurs d'autres sources via l'analyse et le formatage de chaînes, c'est donc important.
2. Si vous définissez une plage de 00:00:00.000 à 23:59:59.999 , vous ne pouvez pas facilement déterminer la durée de la plage. Au lieu de seulement duration = end - start , vous devez maintenant faire quelque chose comme duration = end - start + epsilon , où epsilon est la précision minimale, comme discuté ci-dessus.

Je rejetterai également votre affirmation selon laquelle il existe une plage "normale" dans la plupart des langages de programmation. En réalité, de nombreuses plages de programmation n'ont pas de types de plage intégrés. Quand ils le font, leur comportement est spécifique à la langue. Il n'y a pas de "normale".

Voir aussi ce post de quora sur la fonction range en Python.

+1 pour la proposition 1, rend les choses flexibles.
Ma première attente était la même que les limites supérieure et inférieure soient incluses, tout comme je le ferais en SQL, X Entre A ET B,
Actuellement en train de le contourner par ce x.isBetween(a, b) || x.isSame(a) || x.isSame(b)

+1

+1

+1 proposition 1

+1

+1

+1

@mj1856 Le comportement par défaut n'est-il pas '()' ?

Is Between 2.9.0+
"Check if a moment is between two other moments, optionally looking at unit scale (minutes, hours, days, etc). **The match is exclusive.**"

isBetween déjà un 3ème paramètre optionnel. Actuellement, la méthode est définie comme function isBetween (from, to, units) où units est facultatif. Cette proposition aboutit à un 4ème paramètre facultatif, donc une implémentation devra gérer deux troisièmes options possibles (exclusive/inclusive vs unités) ou les quatre.

Quelques solutions de contournement (non testées) :

() = x.isBetween(start, end) //totalement exclusif - l'implémentation par défaut à ce moment
(] = x.isAfter(start) && x.isSameOrBefore(end) //exclusif à gauche, inclus à droite
[) = x.isSameOrAfter(start) && x.isBefore(end) //gauche inclus, droite exclusif
[] = !(x.isBefore(a) || x.isAfter(b)) //complètement inclus

Peut-être que les solutions de contournement plus faciles à lire ressemblent à ceci :

() = x.isEntre(a,b)
(] = x.isEntre(a,b) || x.isMême(b)
[) = x.isMême(a) || x.isEntre(a,b)
[] = x.isEntre(a, b) || x.isMême(a) || x.isSame(b) // identique à !(x.isBefore(a) || x.isAfter(b))

Étant donné que les 3e et 4e paramètres seront tous les deux facultatifs, il peut être bon de passer un objet

var options = {
   units: 'milliseconds', // 'year', 'month', etc.
   inclusive: '{)' // '{}', '()', '(}', '{)'
}
m.isBetween(start, end, options)

Où les unités par défaut sont les millisecondes et l'inclusif par défaut est () .

Merde... vous avez raison. Pardon. Reformulation...

Marquer cela à gagner. L'utilisation attendue serait celle de la proposition 1 ci-dessus, qui devrait autoriser un _quatrième_ paramètre facultatif passé à isBetween , contenant l'un des '[]' , '[)' , '()' , '(]' . Il devrait inclure des tests pour les quatre. La valeur par défaut lorsqu'elle n'est pas transmise doit être la même que '()' , qui est également le comportement actuel.

WRT les options - Je n'ai vraiment pas de préférence. On pourrait tout aussi bien passer null dans le troisième paramètre pour accéder au quatrième, ou autoriser l'un ou l'autre élément à être passé comme troisième ou quatrième paramètre, puisque nous sommes limités aux valeurs connues. L'objet options convient également. Quoi que l'implémenteur pense être le plus simple - ou diable, vous pouvez faire tout ce qui précède.

À moins, bien sûr, que quelqu'un d'autre ait une opinion bien arrêtée à ce sujet. :)

Bon départ dans le PR #2943. Nous allons suivre cela dans ce PR. Merci!

+1

J'aurais VRAIMENT aimé utiliser la fonctionnalité de @darrenjennings commit aujourd'hui.

Parlez-vous de cette mise à disposition dans la v2.13 ? @rbreier
https://momentjs.com/docs/#/query/is -between/

C'est exactement ce que je cherchais. Merci beaucoup. J'ai mis à jour et cela fonctionne parfaitement pour moi.

C'était une fonctionnalité géniale et absolument nécessaire !!!!

La seconde où nous avons fusionné isBetween Je savais que certaines personnes voudront spécifier un comportement différent pour les intervalles, mais je n'ai pas encore vu de bonne proposition. En fin de compte, les deux extrémités seraient configurables séparément (qu'elles soient inclusives/exclusives).

Il doit également être rétrocompatible avec la version actuelle.

// proposal 1
m.isBetween(a, b, "()"); // both excluded
m.isBetween(a, b, "[)"); // start included, end excluded

// proposal 2
m.isBetween(a, b, "+"); // both included
m.isBetween(a, b, "+-"); // start included, end excluded

console.log('isBetweenFlag', moment('2010-10-19').isBetween('2010-10-19', '2010-10-25',"+"));

lorsque j'utilise la condition ci-dessus, la première erreur m'est signalée, puis la condition va échouer. j'utilise angulaire 6