Moment: السيطرة على سلوك التفرد / التفرد isBetween

أود أيضا هذا.

أوافق ، ستكون هذه ميزة مفيدة لا تصدق. أن تكون قادرًا على الاختيار بين الشامل والحصري بين ، أو تمرير التضمين كحجة منطقية سيكون أمرًا رائعًا.

في الواقع ، هناك القليل من التفكير الذي يحتاج إلى الخوض في هذه الوظيفة أكثر مما هو معروض حاليًا أو ما يتم اقتراحه.

في سيناريوهات العالم الحقيقي ، تكون قيمة البداية شاملة دائمًا ، ولكن القيمة النهائية إما شاملة أو حصرية _ اعتمادًا على الدقة_. على وجه التحديد ، إذا كانت القيمة تتضمن مكونًا زمنيًا ، فيجب أن تكون القيمة النهائية حصرية. إذا لم يتضمن مكونًا زمنيًا ، فيجب أن يكون "شاملاً".

فكر في الأمر بهذه الطريقة. إذا سألتك عن عدد الأيام بين 1 يناير و 3 يناير - الإجابة هي ثلاثة أيام . لكن إذا سألتك عن عدد الساعات بين 1:00 و 3:00 ، فالجواب هو ساعتان . البشر يفعلون هذا بشكل طبيعي. له تأثير على كيفية قياس المدد بين الفترات (مثل moment#diff ) ، وكيف نختبر قيمة لمعرفة ما إذا كانت في النطاق (مثل moment#inBetween ).

السلوك الحالي لـ moment#isBetween حصري تمامًا ، بغض النظر عن الدقة. هذا ليس مفيدًا جدًا.

السلوك الحالي moment#diff شامل في البداية ، وحصري في النهاية ، مرة أخرى ، بغض النظر عن الدقة. هذا صالح للوقت ، والخلل غير صالح لأيام. في الواقع ، المثال في المستندات هو:

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

عندما تكون في الواقع ، يتوقع معظم الناس أن تكون النتيجة يومين.

المشكلة النهائية هي أن الكائن moment هو وحدة زمنية سرية ، ولكن في كثير من الحالات نحاول التعامل معها على أنها تاريخ في التقويم ، وهنا تبدأ الآثار الجانبية في الظهور.

فكر في الأمر بهذه الطريقة. إذا سألتك عن عدد الأيام بين 1 يناير و 3 يناير - الإجابة هي ثلاثة أيام. لكن إذا سألتك عن عدد الساعات بين 1:00 و 3:00 ، فالجواب هو ساعتان.

أعتقد أن الإجابة المنطقية (والمتوقعة بالنسبة لي) هي "2" عند سؤال مكتبة التاريخ عن عدد الأيام بين "1 يناير" و "3 يناير". والسبب هو أنه بدون تحديد وقت ، أتوقع أن يتم العمل بين "1 يناير 00:00" و "3 يناير الساعة 00:00". تعتمد طريقة عمل البشر للاختلاف في العالم الحقيقي على السياق ولكني لا أعتقد أن هذا له علاقة بكيفية عمل الأشياء في عالم البرمجة.

إليك كيفية القيام بذلك مع Carbon في PHP ولم أجد أن هذا يمثل مشكلة: https://github.com/briannesbitt/Carbon/blob/master/src/Carbon/Carbon.php#L1070 -1092

والثاني الذي دمجناه هو بين علمت أن بعض الأشخاص سيرغبون في تحديد سلوك مختلف للفترات الزمنية ، لكني لم أر اقتراحًا جيدًا بعد. في النهاية سيكون كلا الطرفين قابلين للتكوين بشكل منفصل (سواء كانا شاملين / حصريين).

يجب أن يكون lt أيضًا متوافقًا مع الإصدارات السابقة للإصدار الحالي.

// 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

لا يمكنني التفكير في سيناريو واقعي لاستبعاد البداية ، لذلك يمكن أن يكون مجرد علم منطقي لاستبعاد النهاية أم لا.

على الرغم من - نوعًا ما أعجبني الاقتراح 1 ، لأنه قريب من تدوين الفاصل الزمني ISO 31-11 المناسب

// 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

أنا لا أحب الاقتراح 2. (بلا إهانة)

: +1: لمقترح واحد.

بصراحة لا يمكنني رؤية أي سيناريوهات تريد فيها صراحة استبعاد أي من الطرفين وليس كليهما. حتى لو كنت تحاول رؤية "حتى هذا اليوم" ، يمكنك استخدام اللحظة (التاريخ) .endOf ("اليوم") كتاريخ الانتهاء ، والذي سيعطيك 11: 59.59 مساءً.

أعتقد أنه يجب أن يكون هناك فقط علامة منطقية لجعلها شاملة / حصرية ، تمامًا مثل النطاق "العادي" في معظم لغات البرمجة. اجعل الأمر بسيطًا لمنع الالتباس - إذا كنت تريد وقتًا _قبل وقت انتهاء_ وقت الانتهاء ، فهناك طرق أخرى للحصول عليه.

mckinnsb - عادة ما يتم تجنب هذا النهج لسببين:

1. تصبح الدقة مهمة. في JavaScript ، سيكون آخر وقت ممكن في اليوم القياسي هو 23:59:59.999 ، لكن في اللغات الأخرى يمكن أن يكون 23:59:59 ، أو 23:59:59.9999999 . نحن نتفاعل مع قيم من مصادر أخرى عبر تحليل السلسلة وتنسيقها ، لذلك هذا مهم.
2. إذا حددت نطاقًا من 00:00:00.000 إلى 23:59:59.999 - لا يمكنك بسهولة تحديد مدة النطاق. بدلاً من duration = end - start ، عليك الآن أن تفعل شيئًا مثل duration = end - start + epsilon ، حيث تمثل epsilon الحد الأدنى من الدقة ، كما نوقش أعلاه.

سأرفض أيضًا تصريحك بأن هناك نطاقًا "عاديًا" في معظم لغات البرمجة. في الواقع ، لا تحتوي العديد من نطاقات البرمجة على أنواع نطاقات مضمنة. عندما يفعلون ذلك ، يكون سلوكهم محددًا بلغة معينة. لا يوجد "طبيعي".

راجع أيضًا هذا المنشور quora حول range في بايثون.

+1 للمقترح 1 ، يجعل الأمور مرنة.
كان توقعي الأول هو نفسه تضمين الحدود العليا والسفلى ، تمامًا كما أفعل في SQL ، X بين A و B ،
يعمل حاليًا حول هذا x.isBetween(a, b) || x.isSame(a) || x.isSame(b)

+1

+1

اقتراح +1 1

+1

+1

+1

@ mj1856 أليس السلوك الافتراضي '()' ؟

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 بالفعل على معلمة اختيارية ثالثة. يتم تحديد الطريقة حاليًا على أنها function isBetween (from, to, units) حيث units اختيارية. ينتج عن هذا الاقتراح معلمة اختيارية رابعة ، لذلك سيتعين على التنفيذ التعامل مع خيارين ثالثين محتملين (حصري / شامل مقابل الوحدات) أو الأربعة جميعها.

بعض الحلول (لم يتم اختبارها):

() = x.isBetween (البداية ، النهاية) // حصري تمامًا - التنفيذ الافتراضي في هذا الوقت
(] = x.isAfter (البدء) && x.isSameOrBefore (النهاية) // اليسار حصريًا واليمين شاملاً
[) = x.isSameOrAfter (البدء) && x.isBefore (النهاية) // اليسار شاملاً واليمين باستثناء
[] =! (x.isBefore (a) || x.isAfter (b)) // شامل تمامًا

ربما يكون من الأسهل قراءة الحلول البديلة مثل هذا:

() = x.is بين (أ ، ب)
(] = x.is بين (أ ، ب) || x.is نفس (ب)
[) = x.isSame (أ) || x.is بين (أ ، ب)
[] = x.isBetween (a، b) || x. هو نفسه (أ) || x هو نفس (ب) // مثل! (x.isBefore (a) || x.isAfter (b))

نظرًا لأن المعلمتين الثالثة والرابعة ستكونان اختياريتين ، فقد يكون من الجيد تمرير كائن

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

حيث تكون الوحدات الافتراضية ملي ثانية ويكون الافتراضي الشامل هو () .

حماقة .. يا رفاق على حق. آسف. إعادة صياغة ...

بمناسبة هذا ما يصل لقمة سائغة. سيكون الاستخدام المتوقع هو الاقتراح 1 أعلاه ، والذي يجب أن يسمح بتمرير المعلمة الاختيارية الرابعة _ الرابعة إلى isBetween ، والتي تحتوي على '[]' ، '[)' ، '()' ، '(]' . يجب أن تشمل اختبارات لجميع الأربعة. يجب أن يكون الإعداد الافتراضي عند عدم تمريره هو نفسه '()' ، وهو أيضًا السلوك الحالي.

WRT الخيارات - حقًا ليس لدي تفضيل. يمكن للمرء أيضًا تمرير null في المعلمة الثالثة للوصول إلى المعامل الرابع ، أو السماح بتمرير أي عنصر كمعامل ثالث أو معامل رابع ، نظرًا لأننا مقيدون بالقيم المعروفة. كائن الخيارات جيد كذلك. مهما كان ما يعتقده المنفذ هو الأسهل - أو هيك ، يمكنك فعل كل ما سبق.

ما لم يكن ، بالطبع ، شخص آخر لديه رأي قوي في ذلك. :)

بداية جيدة في PR # 2943. سنتعقب هذا في تلك العلاقات العامة. شكرا!

+1

كنت أرغب حقًا في استخدام الوظيفة في darrenjennings الالتزام اليوم.

هل تتحدث عن هذا الذي تم توفيره في الإصدار 2.13؟ تضمين التغريدة
https://momentjs.com/docs/#/query/is -between /

هذا هو بالضبط ما كنت أبحث عنه. شكرا جزيلا لك. لقد قمت بتحديث وهذا يعمل بشكل مثالي بالنسبة لي.

كانت هذه ميزة رائعة ومطلوبة للغاية !!!!

والثاني الذي دمجناه هو بين علمت أن بعض الأشخاص سيرغبون في تحديد سلوك مختلف للفترات الزمنية ، لكني لم أر اقتراحًا جيدًا بعد. في النهاية سيكون كلا الطرفين قابلين للتكوين بشكل منفصل (سواء كانا شاملين / حصريين).

يجب أن يكون lt أيضًا متوافقًا مع الإصدارات السابقة للإصدار الحالي.

// 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'). isBet بين ('2010-10-19'، '2010-10-25'، "+"))؛

عندما أستخدم الشرط أعلاه ، سيظهر لي الخطأ الأول ومن ثم ستفشل الحالة. أنا أستخدم الزاوية 6