Runtime: إضافة GetISOWeekOfYear ()

لماذا لا تضيف فقط عضوًا جديدًا لـ ISO إلى CalendarWeekRule ؟

svick ثم تجاهل firstDayOfWeek (ما لم يكن يوم الإثنين)؟ تحدد ISO 8601 يوم الاثنين كأول يوم في الأسبوع.

إنه في الأساس GetWeekOfYear الموجود مع CalendarWeekRule.FirstFourDayWeek + DayOfWeek.Monday وقليلًا من التغيير السلوكي. راجع https://blogs.msdn.microsoft.com/shawnste/2006/01/24/iso-8601-week-of-year-format-in-microsoft-net/

تضمين التغريدة

من المحتمل أن يكون الخيار الأفضل هو طلب أن يكون firstDayOfWeek يوم الإثنين (ورمي خلاف ذلك).

ولكن في هذه المرحلة ، قد يكون الاقتراح الأصلي بإضافة طريقة جديدة أفضل.

أعتقد أنه من الأفضل إضافة عضو جديد إلى CalendarWeekRule enum. شيء من هذا القبيل Iso8601 أو Iso8601ModayFirstDayOfWeek. لا أعتقد أننا بحاجة إلى إضافة واجهة برمجة تطبيقات جديدة لذلك. إذا وافقت ، هل يمكنك تحديث الاقتراح؟

CCshawnsteele

قد تكون الفكرة الأخرى هي إضافة العضو الجديد Iso8601 إلى تعداد CalendarWeekRule

وبعد ذلك ، لديك زيادة في الطريقة

System.Globalization.Calendar.GetWeekOfYear (التاريخ والوقت ، قاعدة CalendarWeekRule) ؛

التي تفترض أن يوم الاثنين هو أول أيام الأسبوع.

وجعل System.Globalization.Calendar.GetWeekOfYear (DateTime time، CalendarWeekRule rule، DayOfWeek firstDayOfWeek) ؛ لرمي إذا لم يكن firstDayOfWeek يوم الإثنين والحكم هو Iso8601.

قد نقوم بإدراج جميع المقترحات البديلة ويمكننا مناقشة ذلك مع لجنة التصميم.

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

iSazonov لهذا السبب اقترحت الفكرة الأخرى للحصول على الحمل الزائد

C# System.Globalization.Calendar.GetWeekOfYear(DateTime time, CalendarWeekRule rule);

والتي تفترض أن يوم الاثنين هو أول أيام الأسبوع.

أود أن أدرج جميع خيارات التصميم البديلة في وصف هذه المشكلة ومن ثم يمكننا اختيار الأفضل منها عند مناقشتها مع لجنة التصميم.

سوف أقوم بتحديث الاقتراح بأفكارك.

tarekgh تحديث API المقترحة. لا تتردد في التصحيح إذا تخطيت شيئًا.

شكرًا ، iSazonov @ لقد قمت بتعديله قليلاً ولكن لم أغير أي شيء في الاقتراح.

إضافة Iso8601Week إلى السرد فكرة معقولة.
إحدى الملاحظات الغريبة التي لاحظتها هي أن بعض التطبيقات تريد معرفة أسبوع ISO ، ولكن بعد ذلك يسألون المواقع / الثقافات عن تفضيل حساب الأسبوع. أي نوع من الأعمال يناسب بعض المناطق المحلية التي تم تعيينها لقواعد أسبوع ISO ، ولكن بعد ذلك تتعارض مع المناطق الأخرى.

ShawnSteele ما هو بالضبط اقتراحك هنا بخصوص ملاحظتك الخاصة؟ أعتقد أن Windows قد يحتاج إلى البدء في تحديد المواقع التي تحتاج إلى أسابيع ISO وسيقوم إطار العمل بتعيين هذه المواقع لاستخدام قيمة التعداد الجديدة التي نقدمها.

tarekgh شيئين:
1) التطبيقات التي تريد صراحة قواعد أسبوع ISO لأن هذه هي الطريقة التي يعمل بها التطبيق ربما تحتاج إلى GetISOWeekOfYear (). يبدو الأمر سخيفًا بالنسبة إلى التطبيق الذي "يحتاج" إلى سلوك ISO للحصول على تقويم لثقافة / لغة ثم محاولة تصحيحه. يريدون سلوكًا صريحًا ، يجب أن يكون سهلاً إلى حد معقول.
2) تنوي بعض الثقافات أن يكون لها سلوك أسبوع ISO. من المحتمل أن يحدد إطار العمل سلوك قاعدة أسبوع ISO عندما يرى Windows LOCALE_IFIRSTWEEKOFYEAR من "2" (أول أربعة أيام في الأسبوع).

شكرا شاونستيل

التطبيقات التي تريد صراحة قواعد أسبوع ISO لأن هذه هي الطريقة التي يعمل بها التطبيق ربما تحتاج إلى GetISOWeekOfYear ()

لذا فأنت تقترح ألا تكون واجهة برمجة التطبيقات الجديدة جزءًا من فصل التقويم. يمكن أن تكون واجهة برمجة تطبيقات ثابتة في DateTimeFormInfo على سبيل المثال. حق؟

تنوي بعض الثقافات أن يكون لها سلوك أسبوع ISO. من المحتمل أن يحدد إطار العمل سلوك قاعدة أسبوع ISO عندما يرى Windows LOCALE_IFIRSTWEEKOFYEAR من "2" (أول أربعة أيام في الأسبوع).

هذه تفاصيل التنفيذ ، يمكننا التحدث أكثر عن ذلك عندما سنقوم بتنفيذه. شكرا على ملاحظاتك.

لذا فأنت تقترح ألا تكون واجهة برمجة التطبيقات الجديدة جزءًا من فصل التقويم. يمكن أن تكون واجهة برمجة تطبيقات ثابتة في DateTimeFormatInfo على سبيل المثال. حق؟

ربما يكون ذلك أكثر ملاءمة ، نعم.

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

tarekgh - أعتقد أن هذا يعتمد على حالة (حالات) الاستخدام الرئيسية. في تجربتي ، ترغب العديد من التطبيقات صراحة في أسبوع ISO ، والسلوك المعتمد على الثقافة غير ذي صلة.

من غير الواضح بالنسبة لي ما إذا كانت هناك حالة استخدام معقولة حيث يكون تفضيل الثقافة لآلية عد أسبوع ISO مثيرًا للاهتمام للتطبيق على الرغم من أن الثقافات الأخرى قد تستخدم أنظمة مختلفة. يبدو أن غالبية التطبيقات تريد سلوك أسبوع ISO المستقل عن الثقافة.

هل هناك شيء مثل سلوك أسبوع ISO المعتمد على الثقافة؟ ألا يتعارض ذلك مع الفكرة الكاملة للمعيار؟ : التفكير:

أنا شخصياً أحب ما نتجه إليه الآن أفضل بكثير من إضافة قيمة تعداد وإلقاء مجموعة من الحجج.

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

khellang هذا نوع من وجهة نظري. تستخدم بعض المناطق أسبوع ISO كممارسة ثقافية أيضًا. في بعض الأحيان يكون هناك ارتباك حول ما إذا كان البرنامج يريد معيار ISO أو ممارسة شائعة للمنطقة.

من السخف أن تسأل عن النسخة الثقافية لأسبوع ISO ، لكن من العدل أن نسأل عما إذا كانت الثقافة تستخدم أسبوع ISO بشكل افتراضي.

إذا كنا نسير في الاتجاه ، أعتقد أنه من المنطقي النظر في جميع كائنات ISO801 والتوافق مع فائدة Unix date .
https://en.wikipedia.org/wiki/ISO_week_date#Relation_with_the_Gregorian_calendar

• الأسبوع الأول
• الاسبوع الماضي
• أسابيع في السنة
• أسابيع في الشهر

http://man7.org/linux/man-pages/man1/date.1.html

• تاريخ / وقت الإخراج -I بتنسيق ISO 8601
• %g آخر رقمين من العام من رقم أسبوع ISO (انظر٪ G)
• %G سنة من رقم أسبوع ISO (انظر٪ V) ؛ عادة ما تكون مفيدة فقط مع٪ V
• %V أسبوع ISO ، مع اعتبار الاثنين أول يوم في الأسبوع (01..53)

iSazonov @ حدّث الاقتراح إذا كنت تريد إضافة الوظائف الأخرى أيضًا.

تضمين التغريدة

ل

ج #
// غير معرّف في ISO 8601 لذا يمكن إزالته
عام ثابت int GetISOWeeksPerMonth (DateTime time) ؛

I prefer to remove this as it is not defined in the ISO 8601. we have the option later to add it if it is really needed. 

for 

```C#
        //-I output date/time in ISO 8601 format
        public static string GetISODatetimeFormat(DateTime time);
       // Additionally or alternatively we could implement formatting method
        public static string FormatISODatetime(DateTime time);

نحن لا نضيف واجهات برمجة التطبيقات للتنسيق هنا. أيضًا ، هل ألقيت نظرة على https://docs.microsoft.com/en-us/dotnet/standard/base-types/standard-date-and-time-format-strings نحن ندعم بالفعل تنسيق تاريخ ISO. انظر إلى محددات "o" و "r". أعتقد أنه يجب علينا إزالة واجهات برمجة التطبيقات هذه من الاقتراح. إذا كنت توافق ، يرجى تحديث الاقتراح مرة أخرى ويمكننا المتابعة من هنا. شكرا.

أنا موافق.

ماذا بالضبط

ج #
عام ثابت int GetISOYearOfISOWeek (DateTime time) ؛

""
يفعل؟ هل يمكنك إعطاء بعض الأمثلة؟

عذرًا ، أنا أترصد في الغالب حول هذا الموضوع ، ومع ذلك أردت أن أشير إلى أن أسابيع ISO متجاورة عبر انتقال العام الجديد من 31 ديسمبر إلى 1 يناير ، لذلك قد يبدأ الأسبوع الأول من العام الجديد في ديسمبر من العام السابق ، أو قد يشمل الأسبوع 53 من عام واحد 1 يناير من العام التالي.

في هذه الحالات ، ينتمي "الأسبوع" إلى العام السابق أو العام التالي ، مما قد يتسبب في حدوث سلوك غريب مثل أن يكون الأول من يناير جزءًا من أسبوع العام السابق. مما يعني أنه من المثير للاهتمام معرفة السنة التي سيتم اعتبار أسبوع ISO جزءًا منها ، على سبيل المثال: 1 يناير 2005 هو 2004-W53-6 على سبيل المثال.

تحتوي ويكيبيديا على ملخص معقول للسلوك https://en.wikipedia.org/wiki/ISO_week_date

لاحظ أنه إذا كنت لا تحسب أسابيع ISO ، فإن السنة هي السنة الميلادية فقط ، لذا فإن التاريخ المنسق ISO لـ 1 يناير 2005 سيظل 2005-01-01 - فقط عندما يتم استخدام أرقام الأسبوع هي السنوات الحصول على غريب.

لذا فإن "GetISOYear" ليس كافيًا ، لأنه ينطبق فقط عند العد حسب أسبوع ISO. أعتقد أن GetISOYearOfISOWeek وصفي جدًا ولا يمكنني التفكير في أي شيء أفضل.

شكرًا shawnsteele لقد وضعت علامة على أن المشكلة جاهزة للمراجعة.

بالتفكير أكثر في واجهات برمجة التطبيقات المقترحة ، أعتقد أنه سيكون من الأفضل تقديم فئة ISOCalendar بدلاً من إضافة هذه الأساليب الثابتة إلى فئة التقويم. أعني أننا سننفذ تقويم ISO الكامل ونضيف جميع الوظائف المطلوبة. ما رأيك في ذلك؟

ما هو الشعور في الأنواع المتداخلة؟ Calendar.ISO.GetWeekOfYear ؟

tarekgh مع الأخذ في الاعتبار أن تقويم ISO مستقل عن الثقافة والطرق المقترحة ثابتة ، يبدو اقتراحك جيدًا جدًا وستكون واجهة برمجة التطبيقات سهلة الاكتشاف.

تضمين التغريدة

ما هو الشعور في الأنواع المتداخلة؟ Calendar.ISO.GetWeekOfYear؟

هل تقصد أن ISO ستكون فئة ثابتة؟ قد يكون هذا جيدًا ولكن ما زلت أفضّل الحصول على فئة IsoCalendar بدلاً من ذلك. السبب هو أنني أرى أن ISO عبارة عن تقويم بحد ذاته (مثل التقويم الغريغوري) ويمكن استخدامه كأي تقويم آخر. حتى موارد التقويم (القياسية ، والكتب ، والمواقع ... إلخ) تشير إليها دائمًا كتقويم.

تضمين التغريدة

مع الأخذ في الاعتبار أن تقويم ISO مستقل عن الثقافة والطرق المقترحة ثابتة ، فإن اقتراحك يبدو جيدًا جدًا وستكون واجهة برمجة التطبيقات سهلة الاكتشاف.

أوافق على أنها ثقافة مستقلة ولكن هذا لا يهم حقًا لأن لدينا بالفعل بعض التقويمات التي لا تتعلق بثقافات معينة (مثل JulianCalendar). لا تختلف مشكلة قابلية الاكتشاف عن أي تقويم آخر ندعمه اليوم. أود أن أزعم أن أي شخص مهتم بوظيفة ISO سيبحث عن تقويم ISO بدلاً من محاولة العثور على بعض طرق فئة التقويم.

FWIW ، أحب فكرة Calendar.ISO - على غرار طريقة التشفير .UTF8. يفترض أنه يمكن أن يكون ISOCalendar.

ومع ذلك ، لا يزال هناك GetISOYearForISOWeek () مما يجعله وظائف إضافية أكثر من التقويمات الأخرى.

يكاد يجعلني أعتقد أنه يجب أن يكون هناك نموذج ISOWeekCalendar آخر ، لأنني لست متأكدًا مما يحدث لـ ISOCalendar عندما تقوم بتمريره إلى واجهات برمجة التطبيقات للتنسيق. كيف يعرف النظام تنسيقه كـ 2005-01-01 (تنسيق تاريخ ISO) أو 2004-W53-6 (تنسيق أسبوع ISO)

تعجبني فكرة Calendar.ISO - على غرار الطريقة التي يوجد بها Encoding.UTF8. من المفترض أنه يمكن أن يكون ISOCalendar.

مع ذلك ، سنحتاج ISOCalendar على أي حال. وجود خاصية Calendar.ISO إضافية يمكننا الحصول عليها إذا ثبت أنها مفيدة حقًا. لكننا لم نفعل ذلك مع التقويمات الأخرى. Imean ليس لدينا التقويم الميلادي على سبيل المثال. بشكل عام ، أعتقد أنها قد تكون فكرة جيدة لأن المستخدمين لا يضطرون إلى إنشاء كائن تقويم جديد في كل مرة يريدون استخدامه. وبدلاً من ذلك ، يمكننا إرجاع نسخة التقويم المخبأة.

ومع ذلك ، لا يزال هناك GetISOYearForISOWeek () مما يجعله وظائف إضافية أكثر من التقويمات الأخرى.

لدينا بالفعل نفس الحالات مع التقويمات Lunisolar التي تكشف المزيد من الأساليب الخاصة بتلك التقويمات.

يكاد يجعلني أعتقد أنه يجب أن يكون هناك نموذج ISOWeekCalendar آخر لأنني لست متأكدًا مما يحدث لـ ISOCalendar عندما تقوم بتمريره إلى واجهات برمجة التطبيقات للتنسيق. كيف يعرف النظام تنسيقه كـ 2005-01-01 (تنسيق تاريخ ISO) أو 2004-W53-6 (تنسيق أسبوع ISO)

سيكون تقويم ISO مستقلًا عن الثقافة ولن يتم استخدامه في التنسيق أو التحليل على الإطلاق. على غرار التقويم اليولياني.

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

تضمين التغريدة

هل هناك أي واجهة برمجة تطبيقات أخرى للتقويم بجانب Calendar.GetWeekOfYear(DateTime time, CalendarWeekRule rule, DayOfWeek firstDayOfWeek); تعتقد أنها ستكون مشكلة لتقويم ISO؟ أنا أسأل لأنني أفكر في السماح للمستخدمين باستخدام ISO لأن أي تقويم عادي آخر سيكون ميزة بدلاً من وجود مستخدمين في حالة خاصة يتفاعلون مع تقويم ISO. يمكننا تحديد سلوك Calendar.GetWeekOfYear(DateTime time, CalendarWeekRule rule, DayOfWeek firstDayOfWeek); وسيكون لدينا واجهة برمجة تطبيقات أخرى Calendar.GetWeekOfYear(DateTime time);

tarekgh هممم ، هذه نقطة مثيرة للاهتمام. "CalendarWeekRule" لا معنى لها في هذا السياق. ماذا سيكون السلوك الصحيح؟ تجاهله؟ افعل شيئا اخر؟

TwoDigitYearMax لا معنى له في تقويم ISO حيث تتطلب ISO 4 سنوات.

سيتضمن GetDaysInYear () لتقويم أسبوع ISO 52 أو 53 أسبوعًا من الأيام ، أليس كذلك؟ قد يكون ذلك مألوفًا. وسيكون مختلفًا عن تقويم الأسبوع الذي لا يحتوي على ISO. ولست متأكدًا مما يعنيه ذلك بالنسبة لتقويم أسبوع ISO "الأشهر" ، لأن هذه مفاهيم لا معنى لها في تقويم أسبوع ISO. (الأسابيع هي الأشهر ، نوعًا ما)

يطرح GetLeapMonth السؤال عما إذا كان عام 52/53 أسبوعًا في تقويم أسبوع ISO يحتوي على مفهوم الأسابيع الكبيسة؟

يوفر ISO مفهوم تنسيقات التاريخ بتنسيق تقليدي 2018-04-16 ، أو بتنسيق أسبوع من العام ، 2018-W16-1 - يمكن استخدام كائن التقويم في DTFI.Calendar. مما يعني أنه يمكن استخدامه للتنسيق.

عادةً ما يحدد DTFI كيفية تنسيق التقويم ويوفر التقويم الرياضيات. ومع ذلك ، فإن الشيء الرئيسي في تقويم ISO هو أن ISO تحدد التنسيق صراحة (على الرغم من أن دقة التنسيق يمكن أن تختلف). الاختلافات المسموح بها تدور حول الدقة والمتغير الفردي لتنسيق ISO مقابل تنسيق ISO Week.

ربما يحتاج أي حل إلى عدم الخلط بين سؤال ISO / التنسيق.

TwoDigitYearMax لا معنى له في تقويم ISO حيث تتطلب ISO 4 سنوات.

أعتقد أن هذا يمكن أن يتصرف مثل التقويم الغريغوري على أي حال. إذا كانت ISO تستخدم العام المكون من 4 أرقام ، فلن يؤثر TwoDigitYearMax على أي شيء في حساب التطبيق. أنا لا أرى مشكلة حقيقية هنا.

سيتضمن GetDaysInYear () لتقويم أسبوع ISO 52 أو 53 أسبوعًا من الأيام ، أليس كذلك؟ قد يكون ذلك غريبًا. وسيكون مختلفًا عن تقويم الأسبوع الذي لا يحتوي على ISO. ولست متأكدًا مما يعنيه ذلك بالنسبة لتقويم أسبوع ISO "الأشهر" ، لأن هذه مفاهيم لا معنى لها في تقويم أسبوع ISO. (الأسابيع هي الأشهر ، نوعًا ما)

انظر إلى https://en.wikipedia.org/wiki/ISO_week_date حيث تنص على "

An ISO week-numbering year (also called ISO year informally) has 52 or 53 full weeks. That is 364 or 371 days instead of the usual 365 or 366 days. The extra week is sometimes referred to as a leap week, although ISO 8601 does not use this term.

مما يعني أن سنة ISO هي إما 364 أو 371 يومًا.

يطرح GetLeapMonth السؤال عما إذا كان عام 52/53 أسبوعًا في تقويم أسبوع ISO يحتوي على مفهوم الأسابيع الكبيسة؟

سيعود GetLeapMonth دائمًا 0 لأنه لا يوجد مفهوم لشهر كبيسة في تقويم ISO.
ستُرجع IsLeapDay و IsLeapMonth دائمًا القيمة false. يمكن أن يعود IsLeapYear صحيحًا للسنوات التي تحتوي على 371 يومًا.

يوفر ISO مفهوم تنسيقات التاريخ بتنسيق تقليدي 2018-04-16 ، أو بتنسيق أسبوع من العام ، 2018-W16-1 - يمكن استخدام كائن التقويم في DTFI.Calendar. مما يعني أنه يمكن استخدامه للتنسيق.
عادةً ما يحدد DTFI كيفية تنسيق التقويم ويوفر التقويم الرياضيات. ومع ذلك ، فإن الشيء الرئيسي في تقويم ISO هو أن ISO تحدد التنسيق صراحة (على الرغم من أن دقة التنسيق يمكن أن تختلف). الاختلافات المسموح بها تدور حول الدقة والمتغير الفردي لتنسيق ISO مقابل تنسيق ISO Week.
ربما يحتاج أي حل إلى عدم الخلط بين سؤال ISO / التنسيق.

لن يرتبط تقويم ISO بأي ثقافة (على غرار التقويمات اليوليانية والليونية). لذا ، فإن التنسيق باستخدام هذا التقويم لن يكون مصدر قلق على أي حال.

بالنسبة إلى Calendar.GetWeekOfYear(DateTime time, CalendarWeekRule rule, DayOfWeek firstDayOfWeek); يمكننا إجبار السلوك على العمل من خلال تجاهل معلمات CalendarWeekRule و DayOfWeek. بالإضافة إلى ذلك ، سنقدم التحميل الزائد الجديد Calendar.GetWeekOfYear(DateTime time) للاستخدام المنطقي. بالطبع ، سنقوم بتوثيق سلوك كلتا الطريقتين ويمكننا شرح سبب تصرفهما على هذا النحو.

أنا لا أضغط حقًا من أجل الحصول على تقويم ISOC ، فأنا أرى فقط الأشخاص يشيرون دائمًا إلى حساب ISO كتقويم ISO في الويب وفي الكتب (مثل حسابات التقويم). لهذا السبب اعتقدت أنه سيكون من المنطقي أن يكون التقويم في حد ذاته ، بدلاً من وجود بعض الأساليب الثابتة كوظائف مساعد.

إذا كنت لا تزال ترى أن هذا محير ، فأنا على ما يرام لاستكشاف المزيد من اقتراحات khellang أو التمسك بالاقتراح الأخير.

مما يعني أن سنة ISO هي إما 364 أو 371 يومًا.

حسنًا ، ما قصدته هو أن تقويم ISO لن يكون تقويمًا بامتداد .ISOWeek. إذا تم استخدامه فقط للحسابات ، فسنحتاج فقط إلى تقويم .ISOWeek (وليس تقويم .ISO) - ولكن إذا تمت إضافة تقويم ISO لاحقًا ، فسيكون ذلك غريبًا.

سيعود GetLeapMonth دائمًا 0 لأنه لا يوجد مفهوم لشهر كبيسة في تقويم ISO.

هناك شهر كبيس في تقويم ISO. لا يوجد شهر كبيس في تقويم أسبوع ISO. (ما لم تستخدم موصّلات الشهر؟ هل تخطط لتعطيل GetMonth () وما شابه ذلك؟)

أعتقد أن "تقويم ISO" و "تقويم أسبوع ISO" له معنى من منظور التنسيق - ولكن يمكنك إنشاء DTFI يعرف كيفية تنسيق تقويم ISO مع أي تقويم ميلادي.

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

لذا ، فإنني أميل إلى إضافة الطريقتين إلى التقويم الغريغوري: GetISOWeek () و GetIsoYearOfIsoWeek () (أو GetIsoWeekYear ()؟) - من شأنها أن تحل المشكلة الفورية دون التسبب في مجموعة من السلوكيات الغريبة الأخرى.

لذا ، فإنني أميل إلى إضافة الطريقتين إلى التقويم الغريغوري: GetISOWeek () و GetIsoYearOfIsoWeek () (أو GetIsoWeekYear ()؟) - من شأنها أن تحل المشكلة الفورية دون التسبب في مجموعة من السلوكيات الغريبة الأخرى.

ما فائدة وجود هذه الطرق في التقويم الميلادي وليس في فصل التقويم المجرد؟ أو كما اقترح khellang أن يكون لديك فئة ISO ثابتة في فئة التقويم (مثل Calendar.ISO.GetISOWeek)؟

كنت أفترض أن Calendar.ISO سيكون تقويم ISOCalendar "الكامل". ولكن إذا كانت مجرد طرق قليلة ، فقد تنجح على ما أعتقد ،

سيكون ISO فئة ثابتة

ج #
نظام مساحة الاسم
{
تقويم فئة الملخص العام: ICloneable
{
فئة ثابتة عامة ISO
{
عام ثابت int GetISOWeekOfYear (DateTime time) ؛
عام ثابت int GetISOFirstWeekOfYear (DateTime time) ؛
عامة ثابتة int GetISOLastWeekOfYear (DateTime time) ؛
عام ثابت int GetISOWeeksPerYear (DateTime time) ؛
عام ثابت int GetISOYearOfISOWeek (DateTime time) ؛
}
}

or we can stick with the original proposal 

```C#
namespace System.Globalization
{
    public abstract class Calendar : ICloneable
    {
        // All ISO 801 objects   (https://en.wikipedia.org/wiki/ISO_week_date#Relation_with_the_Gregorian_calendar)
        public static int GetISOWeekOfYear(DateTime time);
        public static int GetISOFirstWeekOfYear(DateTime time);
        public static int GetISOLastWeekOfYear(DateTime time);
        public static int GetISOWeeksPerYear(DateTime time);

        // Compatibility with Unix date utility (http://man7.org/linux/man-pages/man1/date.1.html)

        // %G year of ISO week number (see %V); normally useful only with %V
        public static int GetISOYearOfISOWeek(DateTime time);
    }
}

سوف أقوم بتحديث الاقتراح ليشمل فئة Calendar.ISO وسأدرج الاقتراح الأصلي كتصميم بديل.

iSazonov إذا كنت موافقًا على ذلك ، فهل يمكنك تحديث الاقتراح؟ أو يمكنني القيام بذلك إذا لم يكن لديك أي اعتراض على تغيير الاقتراح.

وبمجرد أن يكون لديك فئة ثابتة Calendar.ISO ISO يمكنك حذف جميع اللاحقات السابقة واللاحقة من أسماء الطرق

tarekgh لا تتردد في التحديث - اقتراح LGTM.

فعله!

لقد أصلحت الخطأ المطبعي في التعليقات ISO 801 -> ISO 8601

سؤال آخر هنا بخصوص:

ج #
الباحث العام الثابت GetFirstWeekOfYear (DateTime time) ؛
عام ثابت int GetLastWeekOfYear (DateTime time) ؛

Will GetFirstWeekOfYear always return 1? or we are returning the relative Gregorian week number here? 
Will GetLastWeekOfYear return GetWeeksPerYear returned value? or we are returning the relative Gregorian week number here? 

wouldn't be better to have these return DateTime object which returns when the first week starts and when last week end? May we change the names too to be GetYearStart and Get YearEnd? 

```C#
            public static DateTime GetFirstWeekOfYear(DateTime time);
            public static DateTime GetLastWeekOfYear(DateTime time);

آسف ، لم أتابع على طول :)
هذا يبدو سيئا بالنسبة لي. "التقويم" له إعداد أسبوع وهو ليس أسبوع ISO. لذلك إذا كان المقصود أن تكون هذه الأسابيع الأولى / الأخيرة من أسابيع ISO ، فيجب عليهم تحديد تقويم أسبوع ISO.

لا يوجد دليل كيف سيكون "أسبوع ISO الأول" مثيرًا للاهتمام ، هذا دائمًا هو "1" ، أليس كذلك؟ والأسبوع الماضي سيكون مثل "GetLastISOWeekOfYear" - والذي قد يكون ممتعًا بعض الشيء.

تبدو بداية / نهاية عام iso مثيرة للاهتمام بالنسبة لي نظرًا لأنهم نادرًا ما يكون الأول من يناير. يمكنك أيضًا الحصول على الأسبوع # من ذلك التاريخ إذا كنت تريد آخر أسبوع iso # من العام.

تغييرات IsoWeeksPerYear (52/53) ، لذلك يبدو "Per" غريبًا. هناك 16 أونصة للربع (لكل ربع لتر). IsoWeeksInYear؟

GetIsoWeeksInYear هو نفس أسبوع ISO الأخير من العام ، لذلك أفضل أن يختفي الأول / الأخير ، فهما زائدا عن الحاجة.

تعجبني فكرة:
عام ثابت DateTime GetISOWeekYearStart (DateTime time) ؛
عام ثابت DateTime GetISOWeekYearEnd (DateTime time) ؛

هذا هو بالضبط ما كنت أتساءل حول فائدة الحصول على GetFirstWeekOfYear و GetLastWeekOfYear. لذلك يبدو لي أن هذه في الحقيقة ليست هناك حاجة إليها.

لماذا لا تحب إعادة التاريخ والوقت للإشارة إلى بداية ونهاية أي عام؟ لا أشعر بالقوة حيال ذلك ، لكن في الوقت نفسه ، يمكنني رؤية فائدة الحصول على هذه المواعيد. تخيل أن لديك عنصر تحكم في التقويم يمكنه تحديد بداية ونهاية سنوات ISO. لاحظ أنه يمكننا تغيير اسم واجهات برمجة التطبيقات إلى شيء مثل GetYearStart و GetYearEnd.

أربكتني. لقد قلت:

تعجبني فكرة:
عام ثابت DateTime GetISOWeekYearStart (DateTime time) ؛
عام ثابت DateTime GetISOWeekYearEnd (DateTime time) ؛

من الواضح أنه سيتعين عليهم تحديد جزء "ISOWeek" نظرًا لأنهم تقويم ISO فقط.

آسف ، لقد أخطأت في قراءتها على أنها "لا أحب".

ماذا عن التسمية:

C# public abstract class Calendar : ICloneable { public static class ISO { ... public static DateTime GetYearStart(DateTime time); public static DateTime GetYearEnd(DateTime time); } }

هذه التسمية غير كافية.
تقويم "ISO" يشبه تمامًا التقويم الغريغوري الذي نعرفه جميعًا. يبدأ في 2018-01-01 وينتهي في 2018-12-31. لها 365/366 سنة.
تدور هذه المناقشة حول تقويم أسبوع ISO ، والذي يختلف.

لذلك ، إما أن يُطلق على الفصل اسم "ISOWeek" أو تحتاج الطرق إلى تحديد ذلك.

ShawnSteele يبدو أنك فاتتك هذه الطرق داخل فئة ISO بالفعل.

سيكون Calendar.ISO.GetYearStart / GetYearEnd. أو اقتراح آخر

Calendar.ISO.GetFirstWeekStart / GetLastWeekEnd

لا ، لم أفوت ذلك. تحدد "ISO" العديد من الأشياء المختلفة حول تنسيقات التاريخ. لا يعني "ISO" أنه يجب أن يكون تنسيق ISO Week Year.

إما أن يتم استدعاء الفئة ISOWeek ، أو احتياجات التباين "الأسبوع" المحددة في الطريقة.

على سبيل المثال: Calendar.ISOWeek.GetYearStart / GetYearEnd

Calendar.ISO.GetYearStart غامض. أتوقع أن يكون ذلك دائمًا 1 يناير ، وليس بداية عام ISO في الأسبوع

لماذا Calendar.ISO.GetFirstWeekStart / GetLastWeekEnd ليس جيدًا؟

هذا بافتراض أن "الأسبوع الأول" الذي تتحدث عنه هو أسبوع ISO. وهو ما يبدو افتراضًا معقولًا للأشخاص الذين يفهمون نظام تقويم أسبوع ISO ، ومع ذلك أعتقد أنه قد يكون غامضًا بعض الشيء للآخرين.

لا أحب اسم ISOWeek لأن أسماء API الأخرى الموجودة هناك لن تكون منطقية. على سبيل المثال ، وجود ISOWeek.GetWeekOfYear سيكون له اسم "أسبوع" مكرر. إذا كنت تعتقد أن Calendar.ISO.GetFirstWeekStart / GetLastWeekEnd يمكن أن يكون غامضًا ، فيمكننا الحصول على Calendar.ISO.GetYearStart / GetYearEnd

الطرق الأخرى تستخدم "ISOWeek"؟ إذن Calendar.ISO.GetFirstISOWeekStart؟

GetYearStart / End أجد أقل صعوبة ، لكنهم سيحتاجون إلى تضمين ISOWeek. GetISOWeekYearStart / End - مما يجعلها أكثر صعوبة.

الطرق الأخرى تستخدم "ISOWeek"؟ إذن Calendar.ISO.GetFirstISOWeekStart؟

لا. نحن لا نفعل. انظر إلى الاقتراح في أعلى الصفحة ولدينا:

ج #
نظام مساحة الاسم
{
تقويم فئة الملخص العام: ICloneable
{
فئة ثابتة عامة ISO
{
// جميع كائنات ISO 8601 (https://en.wikipedia.org/wiki/ISO_week_date#Relation_with_the_Gregorian_calendar)
عام ثابت int GetWeekOfYear (DateTime time) ؛
الباحث العام الثابت GetFirstWeekOfYear (DateTime time) ؛
عام ثابت int GetLastWeekOfYear (DateTime time) ؛
عام ثابت int GetWeeksPerYear (DateTime time) ؛

       // Compatibility with Unix date utility (http://man7.org/linux/man-pages/man1/date.1.html)

       // %G year of ISO week number (see %V); normally useful only with %V
        public static int GetYearOfWeek(DateTime time);
}

}
""

ماذا عن ISO.GetWeekYearStart / End؟

أجد أن "GetIsoFirstWeekStart" غير لائق. أنت تريد حقًا بداية / نهاية أسبوع ISO. التي تصادف أن تكون بداية الأسبوع الأول ، لكن هذا إعادة توجيه ذهني إضافية غير ضرورية.

GetYearStart في حد ذاته غامض لأنه لا يوضح ما إذا كانت السنة التقويمية أو سنة الأسبوع.

ماذا عن ISO.GetWeekYearStart / End؟

هذا يبدو معقولا بالنسبة لي. سوف أقوم بتحديث الاقتراح وفقًا لذلك إذا لم يعترض أي شخص آخر :-)

بالنسبة لـ GetWeekYearEnd ، هل سيعيد هذا بداية الأسبوع الماضي في السنة؟ أم سيعود آخر يوم من الأسبوع من السنة؟

سأعيد بداية / نهاية العام. (آخر يوم في الأسبوع في GetWeekYearEnd)

سألت لأنه يسأل عن أسبوع نهاية العام :-) أعتقد أن هذا يمكن فهمه عند العودة في اليوم الأول من الأسبوع الذي ينتهي العام. الارتباك الذي أراه الآن هو ، هل يتضح من API ما إذا كنا سنعود الأسبوع أو اليوم؟

بدأت في التفكير مرة أخرى سيكون GetYearStart / End أكثر وضوحًا :-)

بخصوص تعليقك

GetYearStart في حد ذاته غامض لأنه لا يوضح ما إذا كانت السنة التقويمية أو سنة الأسبوع.

سيكون هذا واضحًا لأن المكالمة ستحتوي على كلمة ISO (مثل ISO.GetYearStart) والتي تشير إلى بداية العام لسنة ISO. لا أرى أن هذا أمر غامض حقًا.

أتوقع أن تقوم ISO.GetYearStart () بإرجاع 1 يناير و ISO.GetYearEnd () لإرجاع 31 ديسمبر. هذا هو الفرق بين سنة ISO وسنة أسبوع ISO.

تحدثنا دون اتصال مع ShawnSteele وهنا الاقتراح النهائي الذي اتفقنا عليه والذي يجب أن يزيل أي لبس.

C# namespace System.Globalization { public abstract class Calendar : ICloneable { public static class ISOWeek { public static int GetWeekOfYear(DateTime time); public static DateTime GetYearStart(DateTime time); public static DateTime GetYearEnd(DateTime time); public static int GetWeeksPerYear(DateTime time); public static int GetYearOfWeek(DateTime time); } }

اسمحوا لي أن أعرف ما إذا كان لدى أي شخص أي قلق بشأن الاقتراح حتى أتمكن من تحديث الاقتراح في أعلى الصفحة.

LGTM.

أجل ، هذا يبدو جيدًا. هل من المنطقي تضمين طرق لتنسيق تاريخ أسبوع ISO كسلسلة؟

من ويكيبيديا:

يتم تحديد التاريخ الدقيق بواسطة سنة ترقيم الأسبوع ISO بالتنسيق YYYY ، ورقم أسبوع بالتنسيق ww مسبوقًا بالحرف "W" ، ورقم أيام الأسبوع ، وهو رقم d من 1 إلى 7 ، بدءًا من يوم الاثنين وتنتهي مع الأحد. على سبيل المثال ، يتوافق التاريخ الميلادي في 31 ديسمبر 2006 مع يوم الأحد من الأسبوع الثاني والخمسين من عام 2006 ، ويتم كتابته 2006-W52-7 (في شكل موسع) أو 2006W527 (في شكل مضغوط).

هل هناك سبب يجعل GetWeeksPerYear و GetYearStart و GetYearEnd لا يأخذ فقط int year ؟

الأساليب الموجودة على Calendar تستخدم نظام تسمية مختلف ؛ GetDaysInYear و GetDaysInMonth و GetMonthsInYear . هل يجب أن يكون GetWeeksPerYear بدلاً من GetWeeksInYear للاتساق؟

أجل ، هذا يبدو جيدًا. هل من المنطقي تضمين طرق لتنسيق تاريخ أسبوع ISO كسلسلة؟

بشكل عام ، يتم التنسيق من خلال فئات الثقافة (مثل DateTimeFormatInfo) ولكن حتى الآن لا ندعم أي ثقافة تحتاج إلى هذا التنسيق. قد نفكر لاحقًا في تقديم مشابه لما نقدمه لتنسيق ISO (أي تنسيق "o") الذي يمكن أن يدعم YYYY-Wnn-dd (أو YYYYWnndd). أود أن أفعل ذلك بشكل منفصل عن هذا الاقتراح.

هل هناك سبب يجعل GetWeeksPerYear و GetYearStart و GetYearEnd لا يستغرقان عامًا فقط؟

فكرت في ذلك من قبل ، أعتقد أن المستخدمين سيستخدمون أسبوع ISO بالتزامن مع التقويم الغريغوري. لذلك أنا أؤمن بالسيناريوهات الرئيسية التي سيبدأ الناس بها DateTime وهذا هو السبب في أنني أفضل أن تكون واجهات برمجة التطبيقات هذه تأخذ DateTime وليس رقم السنة. اسمحوا لي أن أعرف إذا كنت تعتقد خلاف ذلك.
أيضًا ، لقد جعلتموني أفكر في سيناريو آخر أعتقد أننا بحاجة إلى دعمه ، وهو الحصول على التاريخ الميلادي من تاريخ ISO. شيء مثل:

C# public DateTime ToDateTime(int year, int week, int day);

أعتقد أن هذا مهم لإضفاء المرونة على التحويل من ISO إلى Gregorian. حتى يتمكن الأشخاص من الذهاب في أي تواريخ. إذا وافقت ، سأضيف هذا إلى الاقتراح أيضًا.

الأساليب الحالية في التقويم تستخدم نظام تسمية مختلف ؛ GetDaysInYear و GetDaysInMonth و GetMonthsInYear. هل يجب استخدام GetWeeksPerYear بدلاً من ذلك GetWeeksInYear لتحقيق الاتساق؟

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

ألا يجب أن يكون هذا DayOfWeek day بدلاً من int day ؟ إنه فعال "حساب تاريخ بالنظر إلى السنة ورقم الأسبوع ويوم الأسبوع" الموضحة في ويكيبيديا

أنا أؤمن بالسيناريوهات الرئيسية التي سيبدأ الناس بها DateTime وهذا هو السبب في أنني أفضل أن تكون واجهات برمجة التطبيقات هذه تأخذ DateTime وليس رقم السنة. اسمحوا لي أن أعرف إذا كنت تعتقد خلاف ذلك.

حاولت تطبيق الأساليب في الاقتراح الحالي والطرق المذكورة أعلاه تحتاج فقط إلى سنة ميلادية. إنها حقًا متاعب عندما تضطر إلى إنشاء DateTime بالكامل (مع الشهر واليوم) فقط للحصول على بداية العام أو تاريخ الانتهاء.

ألا يجب أن يكون هذا هو يوم DayOfWeek بدلاً من يوم int؟

سوف أقوم بتحديث الاقتراح بذلك. أنت على حق ، يجب أن يكون اليوم بين الأحد والاثنين .... السبت

حاولت تطبيق الأساليب في الاقتراح الحالي والطرق المذكورة أعلاه تحتاج فقط إلى سنة ميلادية. إنها حقًا متاعب عندما تضطر إلى إنشاء DateTime كامل (بالشهر واليوم) فقط للحصول على بداية العام أو تاريخ الانتهاء.

القضية التي أخشى أن يواجهها الناس هي سنة الإدخال ، هل هي حقًا السنة الميلادية؟ أم أنها سنة ISO. تعلمون أنه يمكننا الحصول على بعض التواريخ بالميلادي (حوالي 29 ديسمبر) والتي يمكن أن تنتمي إلى العام المقبل في ISO. إن وجود DateTime يزيل هذا الالتباس ، كما أن رقم الشهر واليوم في DateTime مهم جدًا أيضًا لمعرفة خريطة التاريخ لأي سنة ISO. سيكون الاقتراح الآخر هو قبول رقم السنة فقط وهو سنة ISO وليس السنة الميلادية ويمكننا تسمية المعلمة باسم isoWeekYear.

كان ردي الأخير يتعلق فقط

C# public static DateTime GetYearStart(DateTime time); public static DateTime GetYearEnd(DateTime time);

لكنني ما زلت أعتقد أن إعادة التعيين يجب أن تستغرق DateTime وليس سنة فقط.

رقم الشهر واليوم في DateTime مهم جدًا أيضًا لمعرفة خريطة التاريخ لأي سنة ISO.

إنه مهم في بعض الطرق ، نعم ، لكن ليس في الأساليب التي ذكرتها. المعلومة الوحيدة المطلوبة هي سنة ميلادية. من التافه تمرير DateTime.Year إذا كان لديك بالفعل مثيل DateTime ، لكن من غير الضروري تمامًا إنشاء DateTime (ما هي القيم التي أستخدمها للشهر واليوم؟ هل هذا مهم؟ ؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟

راجع للشغل ، هناك سابقة بالفعل لاستخدام int year في Calendar.GetDaysInYear . قد نكون كذلك متسقين.

يمكنني وضع فكرة عن عمليات التنفيذ السريعة الخاصة بي حتى تتمكن من التعرف على واجهات برمجة التطبيقات واستخدامها إذا كنت تريد ذلك؟

إنه مهم في بعض الطرق ، نعم ، لكن ليس في الأساليب التي ذكرتها. المعلومة الوحيدة المطلوبة هي سنة ميلادية. من السهل تمرير DateTime. سنة إذا كان لديك بالفعل مثيل DateTime ، ولكن ليس من الضروري تمامًا إنشاء DateTime (ما هي القيم التي أستخدمها للشهر واليوم؟ هل يهم؟ هل يتم استخدامها؟) فقط لتمريرها.

ماذا يحدث إذا كان لديك عام ميلادي يتجاوز سنتين من ISO؟ هنا المثال ،

الأحد 28 ديسمبر 2008 | 2008-W52-7
الاثنين 29 ديسمبر 2008 | 2009-W01-1

لذلك إذا مررت عام 2008 إلى واجهات برمجة التطبيقات الخاصة بنا ، فسيكون الأمر غامضًا. هذا هو السبب في أنني ذكرت أن واجهات برمجة التطبيقات يجب أن تأخذ DateTime أو يجب أن تأخذ رقم سنة ISO وليس الرقم الميلادي.

راجع للشغل ، هناك سابقة بالفعل لاستخدام int year في Calendar. قد نكون كذلك متسقين.

لا أشعر بالقوة حيال هذا لأن واجهة برمجة التطبيقات هذه ستعيد 7 * GetWeeksInYear (...)

ملاحظة أخرى بخصوص استخدام DayOfWeek لليوم بدلاً من int في واجهة برمجة التطبيقات التالية
C# public DateTime ToDateTime(int year, int week, int day);

عادةً ما يستخدم أسبوع ISO أيامًا من 1 إلى 7 بينما يكون لـ DayOfWeek أيام من الأحد = 0 إلى السبت = 6. هل تعتقد أن هذا يمكن أن يحدث ارتباكًا؟ أيضًا ، إذا استخدمنا DayOfWeek ، فهل تعتقد أننا نقبل قيمة مثل (DayOfWeek) 7 ؟

شيء آخر ، لواجهتي API التاليتين

C# public static class ISOWeek { public static int GetWeekOfYear(DateTime time); public static int GetYearOfWeek(DateTime time); }

هل يجب أن نسميهم GetWeek و GetYear؟ ستتم كتابتها كـ ISOWeek.GetWeek (...) و ISOWeek.GetYear (...]

ربما يكون من المنطقي أن يكون لديك:
c# public DateTime ToDateTime(int year, int week, int day); public DateTime ToDateTime(int year, int week, DayOfWeek day); public DateTime ToDateTime(int year, int weekOfYear); public DateTime ToDateTime(int year, int dayOfYear);

عادةً ما يستخدم أسبوع ISO أيامًا من 1 إلى 7 بينما يكون لـ DayOfWeek أيام من الأحد = 0 إلى السبت = 6. هل تعتقد أن هذا يمكن أن يحدث ارتباكًا؟

لا إطلاقا. لدينا بالفعل تعداد يمثل يوم من الأسبوع. سيكون من العار إذا لم نستخدمه. لماذا نستخدم نوعًا أقل تحديدًا هنا ، ولكن نوعًا أكثر تحديدًا ( DateTime ) في GetWeeksInYear ، GetYearStart و GetYearEnd ؟
أشك في أن أي شخص يهتم كثيرًا بما إذا كان Sunday يمثل 0 أو 1 أو 6 أو 7 . يريدون الأحد فقط ، هذا كل شيء. يجب أن تكون API مسؤولة عن التحويل إلى التمثيل الرقمي الصحيح.

أيضًا ، إذا استخدمنا DayOfWeek ، فهل تعتقد أننا نقبل قيمة مثل (DayOfWeek) 7 ؟

سأقول لا. ماذا سيمثل؟ هل نفترض أنهم يريدون الأحد؟

هل يجب أن نطلق عليهم GetWeek و GetYear ؟

نعم موافق 👍

ماذا يحدث إذا كان لديك عام ميلادي يتجاوز سنتين من ISO؟ هنا المثال ،

الأحد 28 ديسمبر 2008 | 2008-W52-7
الاثنين 29 ديسمبر 2008 | 2009-W01-1

لذلك إذا مررت عام 2008 إلى واجهات برمجة التطبيقات الخاصة بنا ، فسيكون الأمر غامضًا. هذا هو السبب في أنني ذكرت أن واجهات برمجة التطبيقات يجب أن تأخذ DateTime أو يجب أن تأخذ رقم سنة ISO وليس الرقم الميلادي.

ما زلت أعتقد أنك تخلط بين هذا وبين الطرق الأخرى ، والتي تحتاج بالفعل إلى الشهر والتاريخ.

ستكون هذه هي النتيجة إذا مررت عام 2008 إلى الطرق المختلفة:

• GetWeeksInYear : 52
• GetYearStart : 2007-12-31 | 2008-W01-1
• GetYearEnd : 2008-12-28 | 2008-W52-7

وللإكمال فقط ، هذا ما سيقدمه لك عام 2009:

• GetWeeksInYear : 53
• GetYearStart : 2008-12-29 | 2009-W01-1
• GetYearEnd : 2010-01-03 | 2009-W53-7

سيعود دائمًا GetWeeksInYear عدد الأسابيع في السنة المحددة. بغض النظر عن الشهر واليوم. هذا التقويم لا يزال قائمًا على رأس التقويم الغريغوري.
سيعرض كل من GetYearStart و GetYearEnd تاريخ البدء والانتهاء الغريغوري لسنة أسبوع ISO المحددة.

هل يمكنك الخروج بمثال يؤدي فيه وجود شهر ويوم إلى تغيير هذه النتائج بالفعل؟

إليك خلاصة تطبيقي الحالي:

https://gist.github.com/khellang/53b98851b1d23eef97503ebb22612b3c

تضمين التغريدة

سأقول لا. ماذا سيمثل؟ هل نفترض أنهم يريدون الأحد؟

نعم. السيناريو في ذهني هو حصول شخص ما على تاريخ ISO من بعض المصادر (والذي سيكون لديه أيام من 1..7) ثم يريد فقط استدعاء إطار العمل مع. إذا لم نتعامل مع 7 على أنها يوم الأحد ، فيجب على المتصل أن يفعل ذلك (اليوم 7٪) قبل الاتصال بنا.

ما زلت أعتقد أنك تخلط بين هذا وبين الطرق الأخرى ، والتي تحتاج بالفعل إلى الشهر والتاريخ.

أعتقد أنني لست مرتبكًا أو ربما ما زلت مرتبكًا :-)
من مثالك يبدو عندما ذكرت عام 2008 ، فأنت تقصد أن عام 2008 هو عام ISO وليس العام الميلادي. هذا ما حاولت قوله أن واجهات برمجة التطبيقات تأخذ رقم سنة ISO. انظر إلى تعليقي السابق بأنني قلت or it has to take the ISO year number and not the Gregorian number. .

فمثلا:

إن وجود شخص ما لديه DateTime ومجرد تجاوز DateTime. العام إلى واجهات برمجة التطبيقات سيكون افتراضًا خاطئًا. وسيحتاجون إلى فعل شيء مثل:

ج #
DateTime dt = new DateTime (2008 ، 12 ، 29) ؛
DateTime yearStart = ISOWeek.GetYearStart (ISOWeek.GetYear (dt)) ؛ // ISOWeek.GetYear (dt) سيعود 2009 وليس 2008.

This will return a different value than if you calling 

```C#
    DateTime yearStart = ISOWeek.GetYearStart(dt.Year);

هل أفتقد أي شيء هنا؟ ولكن إذا كان هذا يتطابق مع ما تفكر فيه ، فأنا على ما يرام لأن واجهات برمجة التطبيقات تأخذ رقم السنة فقط وسنحتاج إلى توضيح رقم هذا العام هو رقم سنة ISO وليس رقم السنة الميلادية. ربما يمكننا تسمية المعلمة باسم isoYear أو نحو ذلك.

لم ألقي نظرة على الكود الخاص بك لكنني سألقي نظرة في أول فرصة.

تضمين التغريدة

أعتقد أن وجود

C# public DateTime ToDateTime(int year, int week, DayOfWeek day);

يكفي هنا. أنا لا أرى هناك حاجة إلى زيادة الحمولة المقترحة.

ولكن إذا كان هذا يتطابق مع ما تفكر فيه ، فأنا على ما يرام لأن واجهات برمجة التطبيقات تأخذ رقم السنة فقط وسنحتاج إلى توضيح رقم هذا العام هو رقم سنة ISO وليس رقم السنة الميلادية.

هل هناك فرق بين "سنة أسبوع ISO" و "سنة ميلادية"؟ أعلم أنها قد تبدأ وتنتهي في تواريخ مختلفة ، ولكن 2009 في التقويم الميلادي هو 2009 في تقويم أسبوع ISO ، أليس كذلك؟ إنه أمر محير فقط بمجرد أن تبدأ في إشراك شهور وأيام.

على الأقل ISOWeek.GetYearStart(ISOWeek.GetYear(dt)) يمكن أن تتكون بشكل جيد.

لست متأكدًا مما إذا كان تسميته year أو isoYear سيجعل الأمر مربكًا أكثر أو أقل

لست متأكدًا مما إذا كان تسميته بالعام أو isoYear سيجعل الأمر مربكًا أكثر أو أقل

إذا كنت تعتقد أن الالتباس سيظل موجودًا ، فقد نحتفظ بالاقتراح الأصلي لتمرير التاريخ والوقت بدلاً من السنة. لن يكون هناك أي لبس في ذلك الوقت.

يمكن أن تتمثل الفكرة الأخرى في وجود حمل زائد على واجهات برمجة التطبيقات هذه ، حيث يستغرق أحدهما DateTime والآخر يستغرق عامًا كما اقترحت. ما زلت أفضل استدعاء المعلمة كـ isoYear لهذا الحمل الزائد.

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

دعنا ننتقل ونؤكد اقتراح واجهات برمجة التطبيقات الذي أعتقد أننا جميعًا نتفق عليه الآن:

C# namespace System.Globalization { public abstract class Calendar : ICloneable { public static class ISOWeek { public static int GetWeekOfYear(DateTime time); public static int GetYear(DateTime time); public static DateTime GetYearStart(int isoYear); public static DateTime GetYearEnd(int isoYear); public static int GetWeeksInYear(int isoYear); public static DateTime ToDateTime(int isoYear, int week, DayOfWeek day); } }

هل هذا يبدو صحيحا؟

هل يجب أن يكون ToDateTime() ToGregorianDateTime() ؟

كيف تتناول "٪ G year of ISO week number (انظر٪ V) ؛ عادة ما تكون مفيدة فقط مع٪ V"؟ يجب أن نضيف الزائد:
c# public static int GetYearOfWeek(int isoYear, int isoWeek);

هل هذا يبدو صحيحا؟

نعم! شكرا لك tarekgh ♥ ️

آسف ، لقد كنت في الخارج لبضعة أيام.

أنا لست مغرمًا جدًا بـ "DayOfWeek". تحتوي تقويمات أسبوع ISO على أسابيع مكافئة لشهور التقويم الميلادي التقليدي ، ويكون رقم اليوم من الأسبوع مشابهًا لرقم اليوم من الشهر في التقويم العادي. لذلك فهو يقوم بتنسيق أشياء مثل 2018-W12-7. لقد عرفنا أي "يوم" يتوافق معه 7 ، إلا أن تنسيق أسبوع ISO يحدد أرقام اليوم. بالتأكيد ، يحتوي .Net على فصل دراسي في DayOfWeek ، ولكن يبدو لي أن هذا يؤدي إلى تغيير غير ضروري للقيم.

كما أنني لست مغرمًا بشكل رهيب بتسمية "isoYear". "Iso Year" ليس شيئًا. تحدد ISO تنسيق التواريخ في شكل تقليدي لا لبس فيه من العام إلى الشهر واليوم ، أو اختياريًا في شكل عام - أسبوع - يوم. "السنة" هو مفهوم ISO صالح لكلا النظامين. (وحتى أنظمة إضافية). في الواقع ، تنص معايير ISO على وجه التحديد على إرشادات لأرقام السنة الميلادية التقليدية ، مثل مطالبتهم بأربعة أرقام لتجنب ارتباك عام 2000. يمكن أن تنطبق "سنة Iso" في حد ذاتها على أي منهما ، على الرغم من أن الأشخاص يقصرون أحيانًا "Iso Week Calendar Year" ، وهو تقليد مضلل ..

يجب أن تكون حقيقة أن هذه الفئة هي فئة IsoWeek كافية لتحديد أن سنة تقويم أسبوع ISO تعني "سنة". إذا كان IsoWeek لا يزال غامضًا جدًا ، فأنا أقترح "IsoWeekCalendar" لتقليل الارتباك بشكل أكبر. إذا شعرت بضرورة استخدام "iso" ، فلماذا لا يتم استخدام "isoWeek" و "isoDay" أيضًا؟ على وجه الخصوص "الأسبوع" له نفس المؤهل تمامًا وهو أن هذا أسبوع تقويم أسبوع Iso وليس أسبوعًا آخر.

ShawnSteele شكرًا على الرنين مرة أخرى!

بالتأكيد ، يحتوي .Net على فصل دراسي في DayOfWeek ، ولكن يبدو لي أن هذا يؤدي إلى تغيير غير ضروري للقيم.

لا أعتقد أننا يجب أن نتعلق كثيرًا بالقيم. يوفر التعداد طريقة لتمثيل "يوم من الأسبوع" ، ويتم استخدامه في جميع أنحاء واجهات برمجة تطبيقات تقويم .NET / التاريخ / الوقت بالفعل. يجب أن نوفر على الأقل حملًا زائدًا معها ، لذا فهي تعمل بسلاسة مع واجهات برمجة التطبيقات الأخرى.

تسمية "isoYear". "Iso Year" ليس شيئًا. تحدد ISO تنسيق التواريخ في شكل تقليدي لا لبس فيه من العام إلى الشهر واليوم ، أو اختياريًا في شكل عام - أسبوع - يوم. "السنة" هو مفهوم ISO صالح لكلا النظامين. (وحتى أنظمة إضافية). في الواقع ، تنص معايير ISO على وجه التحديد على إرشادات لأرقام السنة الميلادية التقليدية ، مثل مطالبتهم بأربعة أرقام لتجنب ارتباك عام 2000. يمكن أن تنطبق "سنة Iso" في حد ذاتها على أي منهما ، على الرغم من أن الأشخاص يقصرون أحيانًا "Iso Week Calendar Year" ، وهو تقليد مضلل ..

يجب أن تكون حقيقة أن هذه الفئة هي فئة IsoWeek كافية لتحديد أن سنة تقويم أسبوع ISO تعني "سنة". إذا كان IsoWeek لا يزال غامضًا جدًا ، فأنا أقترح "IsoWeekCalendar" لتقليل الارتباك بشكل أكبر. إذا شعرت بضرورة استخدام "iso" ، فلماذا لا يتم استخدام "isoWeek" و "isoDay" أيضًا؟ على وجه الخصوص "الأسبوع" له نفس المؤهل تمامًا وهو أن هذا أسبوع تقويم أسبوع Iso وليس أسبوعًا آخر.

نعم ، لهذا قلت:

هل هناك فرق بين "سنة أسبوع ISO" و "سنة ميلادية"؟ أعلم أنها قد تبدأ وتنتهي في تواريخ مختلفة ، ولكن 2009 في التقويم الميلادي هو 2009 في تقويم أسبوع ISO ، أليس كذلك؟ إنه أمر محير فقط بمجرد أن تبدأ في إشراك شهور وأيام.

ج #
عام ثابت int GetWeekOfYear (DateTime time) ؛
عام ثابت int GetYear (DateTime time) ؛

Would it make sense to add overloads that accept `DateTimeOffset` instead of `DateTime`, to make these methods easier to use for people who have to care about time zones? In other words:

```c#
public static int GetWeekOfYear(DateTime time);
public static int GetWeekOfYear(DateTimeOffset time);
public static int GetYear(DateTime time);
public static int GetYear(DateTimeOffset time);

هل من المنطقي إضافة الأحمال الزائدة التي تقبل DateTimeOffset بدلاً من DateTime ، لتسهيل استخدام هذه الأساليب للأشخاص الذين يجب أن يهتموا بالمناطق الزمنية؟

ماذا ستفعل عمليات التنفيذ بالمعلومات الإضافية (تعويض التوقيت العالمي المنسق)؟

تضمين التغريدة

ماذا ستفعل عمليات التنفيذ بالمعلومات الإضافية (تعويض التوقيت العالمي المنسق)؟

أعتقد أن نفس الشيء الذي ستفعله الأحمال الزائدة DateTime مع DateTimeKind أو TimeOfDay : تجاهلها.

أعتقد أن نفس الشيء الذي ستفعله عمليات التحميل الزائدة لـ DateTime مع DateTimeKind أو TimeOfDay : تجاهله.

ألا يتلخص ذلك في نفس المشكلة مع الاضطرار إلى تمرير DateTime إذا كنت مهتمًا فقط بالخاصية Year ؟

من الناحية المثالية ، إذا كان .NET لديه نوع Date خالص ، فإن هذه الأحمال الزائدة ستستغرق ذلك.

من السهل بما يكفي الانتقال من DateTimeOffset إلى DateTime إذا كان هذا كل ما تحتاجه ، أليس كذلك؟

تضمين التغريدة

من السهل جدًا الانتقال من DateTimeOffset إلى DateTime إذا كان هذا كل ما تحتاجه ، أليس كذلك؟

أنه. كنت أتساءل فقط عما إذا كان جعل العمل DateTimeOffset أكثر ملاءمة أمرًا يستحق كل هذا العناء. بهذه الطريقة ، لا يشعر الناس بالإحباط لاستخدام DateTimeOffset عندما يجب عليهم استخدامه.

بهذه الطريقة ، لا يشعر الناس بالإحباط لاستخدام DateTimeOffset عندما يجب عليهم استخدامه.

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

بالنسبة إلى مشكلة DateTimeOffset ، لا أرى ISOWeek تفعل أي شيء مع المناطق الزمنية أو مع الوقت بشكل عام. يتعامل بشكل أساسي مع التاريخ وليس الوقت. لذلك لا أعتقد أننا بحاجة إلى استخدام DateTimeOffset.

بالنسبة لمسألة DayOfWeek ، أحب استخدام النوع الصريح مثل DayOfWeek ولا يزال بإمكاننا السماح بتمرير القيمة 7 يوم الأحد أيضًا. من خلال القيام بذلك ، لن يكون هناك أي مشكلة لأي شخص يحتاج إلى الاتصال بنا بقيم من 1..7 (مع الإرسال إلى DayOfWeek) أو أي شخص يريد الاتصال بنا مع DayOfWeek Sunday..Saturday. لا أحب أن يكون لدي الحمل الزائد الذي يستغرق يومًا من الأسبوع رقمًا بدلاً من DayOfWeek.

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

ما زلت أرى أن هناك فرقًا بين العام الميلادي وسنة ISO.

من فضلك ، إنها سنة ميلادية وسنة أسبوع ISO. سنوات ISO غامضة ، إما "أسبوع ميلادي" أو "أسبوع ISO". على سبيل المثال ، تحدد ISO 8601 التواريخ الترتيبية أيضًا ، على سبيل المثال: 2018-117. هذا تنسيق "ISO" ، ومن الواضح أن عام 2018 في تنسيق ISO هذا سيكون عام ISO. لكنها ليست نفس سنة أسبوع ISO.

إذا كنت أقوم بإنشاء DateTime من تاريخ أسبوع ISO ، فإن الشيء الوحيد المنطقي هو استخدام ISO Week Year. في هذه الحالة "iso" في اسم العام زائدة عن الحاجة. لكي يكون ذلك منطقيًا ، يجب أن يكون:

عام ثابت DateTime ToDateTime (int isoWeekYear، int isoWeekWeek، DayOfWeek isoWeekDay) ؛

إلا أننا قلنا بالفعل أنه فصل "IsoWeek". لذا فإن إضافة هذا أمر سخيف.

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

على أي حال ، لا أمانع إذا شعر الناس بشدة أنهم بحاجة إلى مؤهلين على الرغم من أن اسم الفئة يشير بالفعل إلى مجال تنسيق IsoWeek. ومع ذلك ، إذا كان مؤهلاً بشكل أكبر ، فأنا أعترض بشدة على إدامة إساءة استخدام المصطلح غير المنطقي "عام iso". معظم التنسيقات المحددة ISO 8601 لها عام يتوافق مع العام الميلادي التقليدي. يختلف عام تنسيق أسبوع ISO فقط.

ShawnSteele ما هو اقتراحك هنا؟ فقط أطلق عليها اسم "عام" وليس isoYear؟

tarekgh - بالنسبة لـ DateTimeOffset ، أعتقد أن هذا عنصر عادل للنظر فيه. قد يكون الأشخاص مهتمين بتنسيق نوع ISO 2007-04-05T12: 30-02: 00 ، والذي يتضمن منطقة زمنية. أود أن أشجع بشدة على التبادل باستخدام التوقيت العالمي المنسق ، لكن التواريخ / الأوقات ليست دائمًا جيدة التصرف :(

ShawnSteele ما هو اقتراحك هنا؟ فقط أطلق عليها اسم "عام" وليس isoYear؟

tarekgh نعم ، فقط "السنة". توفر فئة "IsoWeek" سياقًا كافيًا. إذا شعر الناس أن "IsoWeek" لا يزال غامضًا ، فأنا أقترح "IsoWeekFormat" أو ما يجعله أكثر وضوحًا أن هذا كله يتعلق بتنسيق الأسبوع ISO 8601.

لا يوجد سيناريو يكون من المنطقي أن تمر فيه بتنسيق أسبوع غير iso مع أسبوع تنسيق أسبوع ISO ويوم تنسيق iso week.

بالنسبة لـ DateTimeOffset ، أعتقد أن هذا عنصر عادل للنظر فيه. قد يكون الأشخاص مهتمين بتنسيق نوع ISO 2007-04-05T12: 30-02: 00 ، والذي يتضمن منطقة زمنية. أود أن أشجع بشدة على التبادل باستخدام التوقيت العالمي المنسق ، لكن التواريخ / الأوقات ليست دائمًا جيدة التصرف :(

لا أعتقد ذلك. نحن ندعم حاليًا DateTime.ToString ("o") الذي يعطي تنسيق ISO وفقًا لـ DateTime (و DateTimeOffset). لا أتوقع رؤية تنسيق أسبوع Iso بما في ذلك معلومات المنطقة الزمنية. هل المعيار يدعم مثل هذا التنسيق؟

حسنًا ، بناءً على المناقشة الأخيرة هنا هو الاقتراح:

C# namespace System.Globalization { public abstract class Calendar : ICloneable { public static class ISOWeek { public static int GetWeekOfYear(DateTime time); public static int GetYear(DateTime time); public static DateTime GetYearStart(int year); public static DateTime GetYearEnd(int year); public static int GetWeeksInYear(int year); public static DateTime ToDateTime(int year, int week, DayOfWeek day); } }

هل سيكون ذلك معقولاً لكم جميعاً؟

لماذا لا تتضمن واجهة برمجة التطبيقات المقترحة يومًا من الأسبوع؟

int GetDayOfWeek العامة الثابتة (DateTime time) ؛

إذا كنت أرغب في تنسيق تاريخ بتنسيق أسبوع ISO ، فإن هذا الفصل يوفر جزء السنة من تنسيق أسبوع ISO "2018" ورقم الأسبوع "17" ، ولكن لا توجد طريقة لإرجاع يوم الأسبوع "7" لـ هذا الأحد.

قد يكون القياس مثل فئة معلومات التاريخ الميلادي التي توفر السنة والشهر ولكن ليس التاريخ (يوم من الشهر).

لقد فهمت تمامًا أن هذا يشبه إلى حد كبير DateTime.DayOfWeek - ومع ذلك ، يتم تعويض يوم ISO من الأسبوع من التعداد وهو رقم وليس تعدادًا. الشفرة "واضحة" ، ولكنها تتطلب دائمًا تغييرًا ، شيء من هذا القبيل

int isoWeekDay = DateTime.DayOfWeek == 0؟ 7: (int) DateTime.DayOfWeek ؛

الذي يبدو أخرقًا جدًا ، خاصة إذا كان فصل IsoWeek موجودًا بالفعل.

لا أعتقد ذلك. نحن ندعم حاليًا DateTime.ToString ("o") الذي يعطي تنسيق ISO وفقًا لـ DateTime (و DateTimeOffset).

tarekgh - نعم ، المعيار يدعم هذا التنسيق. https://ar.wikipedia.org/wiki/ISO_8601#Combined_date_and_time_representations

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

لماذا لا تتضمن واجهة برمجة التطبيقات المقترحة يومًا من الأسبوع؟

التقويم الميلادي يحتوي بالفعل على هذا. أنا لا أرى حقًا سبب حاجتنا للقيام بذلك؟ كما ذكرت من قبل ، يمكننا النظر في توفير خيارات التنسيق بشكل منفصل عن هذا الاقتراح. لذلك لا حاجة لتقديم API مثل ما تقترحه. لا يزال بإمكان الأشخاص تحويل يوم الأحد إلى 7 إذا احتاجوا إلى ذلك. سيكون من المبالغة في توفير مثل هذه API للقيام بذلك.

نعم ، المعيار يدعم هذا التنسيق. https://ar.wikipedia.org/wiki/ISO_8601#Combined_date_and_time_representations

أنا لا أفسر الفقرة التي تتحدث عنها بنفس الطريقة. هناك فرق بين تمثيل التاريخ وتنسيقه. أرى تنسيق تاريخ ISO يستخدم دائمًا السنة والشهر والأيام (بالإضافة إلى معلومات الوقت والمنطقة الزمنية) ولكني لا أراها في أي مكان يمكنك فيه استخدام رقم أسبوع بتنسيق ISO هذا. https://www.iso.org/iso-8601-date-and-time-format.html

ISO 8601 tackles this uncertainty by setting out an internationally agreed way to represent dates:

YYYY-MM-DD

لقد أربكتني من خلال "تمثيل التاريخ" مقابل "تنسيقه". يمكن تمثيل جميع تواريخ أسبوع ISO حسب DateTimes ولا تحتاج إلى هذا الفصل. تعد تنسيقات ISO Week بشكل أساسي بمثابة اصطلاح لتنسيق التواريخ الميلادية بطريقة مناسبة لبعض الشركات.

السياقات التي اعتدت على رؤية هذه التواريخ هي في نطاق "أسابيع لمشروع" أو "يوم" ، ولكن 2018-W17-05T10: 00: 00 + 02: 00 (و 2018-117T10: 00: 00 + 02: 00) مسموح بها بالتأكيد وفقًا للمعيار. بالتأكيد ، يمكن تمثيله بتنسيق YMD ، لكن ISO 8601 لا يتطلب نموذج YMD لجزء التاريخ ويسمح لمستخدمي المعيار باختيار الطريقة التي يريدون تمثيل جزء التاريخ من تنسيق التاريخ + الوقت الكامل. (يمكن للمستخدمين أيضًا اختيار استخدام التوقيت العالمي المنسق أو عروض زمنية أخرى أيضًا).

بالتأكيد ، تحدد العديد من طلبات التعليقات والمعايير الأخرى تنسيق 2018-04-27 من أجل التناسق وقابلية النقل ، ومع ذلك فإن ISO 8601 ليس مقيدًا.

لكن ISO 8601 ليس مقيدًا.

هل يمكن أن ترسل لي الرابط من معيار ISO يسمح بذلك (أعني السماح بتنسيق مثل 2018-W17-05T10: 00: 00 + 02: 00)؟ أنا أقدر مساعدتك هنا.

أيضًا ، أنا مهتم إذا كان بإمكانك كتابة بعض نماذج التعليمات البرمجية بالطريقة التي تتوقع أن يكتب بها الأشخاص تعليمات برمجية لاستخدام واجهات برمجة التطبيقات المقترحة مع DateTimeOffset؟ أعني ، متى سيكون DateTimeOffset مستفيدًا أكثر من DateTime؟ أو بعبارة أخرى ، متى ستهتم واجهات برمجة التطبيقات الجديدة المقترحة بالوقت على الإطلاق؟

لا أعتقد أن DateTimeOffset يحتاج إلى معالجة الآن. يمكننا استخدام DateTime ومعرفة ما إذا كان الناس يطالبون بـ DateTimeOffset. إذا كان الأمر كذلك ، يمكن إضافته لاحقًا. لا أعتقد أن هذا يجب أن يمنع هذا العمل.

أنا بخير مع الاقتراح الذي نشرته آخر مرة.

ShawnSteele شكرا

سأقوم بتحديث الاقتراح في الأعلى بما يلي:

C# namespace System.Globalization { public abstract class Calendar : ICloneable { public static class ISOWeek { public static int GetWeekOfYear(DateTime time); public static int GetYear(DateTime time); public static DateTime GetYearStart(int year); public static DateTime GetYearEnd(int year); public static int GetWeeksInYear(int year); public static DateTime ToDateTime(int year, int week, DayOfWeek day); } }

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

هذا مثالي بقدر ما أشعر بالقلق ، طارق. شكرا!

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

يؤدي تضمين هذا النوع ضمن التقويم إلى إجبار الجميع على استخدام أسماء مؤهلة طويلة جدًا (على سبيل المثال ، Calendar.ISOWeek.GetWeekOfYear() مقابل ISOWeek.GetWeekOfYear() فقط) ، وبالتالي يبدو ترقية ISOWeek إلى نوع المستوى الأعلى أفضل ، خاصة لأن يساعد في الاكتشاف.

namespace System.Globalization
{
    public static class ISOWeek
    {
        public static int GetWeekOfYear(DateTime time);
        public static int GetYear(DateTime time);
        public static DateTime GetYearStart(int year);
        public static DateTime GetYearEnd(int year);
        public static int GetWeeksInYear(int year);
        public static DateTime ToDateTime(int year, int week, DayOfWeek day);
    }
}

khellang لقد أرسلت إليك دعوة متعاون حتى نتمكن من تعيين المشكلة لك (حدود GH). أرسل لي بمجرد قبولك (التنازل عن نفسي مؤقتًا).
نصيحة احترافية: بدّل الريبو إلى "لا يشاهد" لتجنب أكثر من 500 إشعار يوميًا (ستشترك تلقائيًا في جميع الإشعارات كمتعاون).

فعله! لقد كنت أشاهد الريبو لسنوات على أي حال

terrajobst هل يجب تمييز هذه المشكلة على أنها معتمدة من api؟

نعم ، تمت الموافقة على هذا (وضع علامة على هذا النحو). كان كمبيوتر terrajobst بطيئًا جدًا لإجراء التغيير :(

مجرد سؤال سريع: هل يجب إضافة هذا النوع إلى System.Private.CoreLib (في coreclr) وانتظر حتى تتم مزامنة الكود مع corefx و corert؟ ثم أضف نوع إعادة التوجيه والاختبارات في System.Globalization؟

مجرد سؤال سريع: هل يجب إضافة هذا النوع إلى System.Private.CoreLib (في coreclr) وانتظر حتى تتم مزامنة الكود مع corefx و corert؟ ثم أضف نوع إعادة التوجيه والاختبارات في System.Globalization؟

نعم ، يرجى إضافة الرمز إلى coreclr repo والرجاء CC me على PR. شكرا.

شكرا جزيلا!

tarekgh هل التعزيز في 2.1.1؟

تم تعيينه إلى 3.0 معلم ، لذلك لا تعتقد ذلك 🤔

صيح. 2.1.1 يخدم. نحن لا نضيف ميزات أو إصلاحات غير مهمة إلى فروع الخدمة ، والتي من شأنها زعزعة استقرارها وجعلها في الأساس فرعًا رئيسيًا آخر.

شكرا! أرى 3.0 علامة فارقة في العلاقات العامة.

عادةً ما أقوم بمسح المعالم غير الصحيحة (مثل المستقبل) 1x-2x كل أسبوع لكل من المشكلات والعلاقات العامة.
أنا متأخر قليلاً بسبب بعض الأسعار المرتفعة على طبقي ، آسف. سوف اللحاق بأسرع ما يمكن.

أليس ISOWeek انتهاكًا لإرشادات تسمية إطار العمل؟

paulomorgado اقرأ https://github.com/dotnet/corefx/issues/28933#issuecomment -392873426 زوجان من التعليقات أعلاه.

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

@ Karelz ولكن هل هذه السفينة مع 2.2؟

آسف khellang ، أنا كما في الهاتف.

ولكن هل هذه السفينة مع 2.2؟

للأسف لا. 2.2 هو إصدار تكتيكي محبط من الإصدار / 2.1 فرع في CoreFX repo (صيانة 2.1) - ملاحظة: هذا قرار خاص بإعادة الشراء ، ولا ينعكس بالضرورة في اتفاقيات إعادة الشراء الأخرى (ASP.NET ، CLI ، إلخ). يتدفق الفرع الرئيسي إلى .NET Core 3.0 في CoreFX repo.

متأخر على الحفلة: هل كانت هناك (لا أجد) مناقشة تفكر في إنشاء نوع مخصص (هيكل) لرقم أسبوع؟ - IsoWeek / IsoWeekNumber / WeekNumber تحتوي على خصائص Year و Week .
IMHO يبدو أكثر إيجازًا من الحاجة إلى استدعاء طريقتين للحصول على رقمين يمثلان شيئًا واحدًا.
لست متأكدًا من كيفية استخدام الأشخاص الآخرين لأرقام الأسبوع ، لكنني كنت أحتاج إلى الأسبوع والسنة معًا في معظم الحالات.

هل كان هناك نقاش حول إنشاء نوع مخصص لرقم أسبوع؟

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

IMHO يبدو أكثر إيجازًا من الحاجة إلى استدعاء طريقتين للحصول على رقمين يمثلان شيئًا واحدًا.

ما المكالمات التي تشير إليها؟ ما هي المعلومات التي لديك وما هي المعلومات التي تهتم بها؟

إذا كان لديك "شيء واحد" يتكون من رقمين ، فمن المنطقي جدًا تقسيم هذه الأساليب. كتابة هيكل التفاف وتأليف هذه الأساليب في وقت لاحق أمر تافه.

أيضًا متأخر قليلاً عن الحفلة ، لكن لماذا قيم الإرجاع واحدة int ؟ اعلم أن 2016-01-02 انخفض في الأسبوع 2015.53 و 2019-12-31 سيكون في الأسبوع 2020.01

ما زلت لا أستطيع استخدام شيء مثل هذا:
ج #
الأسبوع الدولي = ISOWeek.GetWeekOfYear (جديد DateTime (2016، 1، 2)) ؛

I do need to check something like every time I need to know a week:
```c#
var d = new DateTime(2016, 1, 2)
int week = ISOWeek.GetWeekOfYear(d);
int year = d.Year;
if (d.Month == 1 && week >= 52)
    year--;
if (d.Month == 12 && week == 1)
   year++;

لماذا لا تعيد Tuple؟
c# public static (int year, int week) GetWeekOfYear(DateTime date);

لماذا لا تعيد Tuple؟

ffes إذا كان لديك var d = new DateTime(2016, 1, 2) ، يجب أن تكون قادرًا على القيام بذلك

var year = ISOWeek.GetYear(d);
var week = ISOWeek.GetWeekOfYear(d);

إذا كنت تريد تدوير ذلك في طريقة واحدة لإرجاع tuple ، فيجب أن يكون ذلك سهلاً للغاية.

فاتني وجود GetYear() . آسف على الضوضاء: بالارتياح: