Runtime: GetISOWeekOfYear() hinzufügen

Warum nicht einfach ein neues Mitglied für ISO zu CalendarWeekRule hinzufügen?

@svick Und dann firstDayOfWeek ignorieren (außer es ist Montag)? ISO 8601 legt den Montag als ersten Wochentag fest.

Es ist im Grunde das bestehende GetWeekOfYear mit CalendarWeekRule.FirstFourDayWeek + DayOfWeek.Monday und ein wenig Verhaltensänderung. Siehe https://blogs.msdn.microsoft.com/shawnste/2006/01/24/iso-8601-week-of-year-format-in-microsoft-net/

@hellang

Wahrscheinlich wäre es eine bessere Wahl, zu verlangen, dass firstDayOfWeek Montag ist (und andernfalls zu werfen).

Aber an diesem Punkt könnte der ursprüngliche Vorschlag, eine neue Methode hinzuzufügen, besser sein.

Ich glaube, es ist besser, der CalendarWeekRule-Aufzählung ein neues Mitglied hinzuzufügen. So etwas wie Iso8601 oder Iso8601ModayFirstDayOfWeek. Ich glaube nicht, dass wir dafür eine neue API hinzufügen müssen. Wenn Sie damit einverstanden sind, könnten Sie bitte den Vorschlag aktualisieren?

CC @shawnsteele

Die andere Idee könnte das Hinzufügen des neuen Members Iso8601 zur Aufzählung CalendarWeekRule sein

Und dann überladen Sie die Methode

System.Globalization.Calendar.GetWeekOfYear (DateTime-Zeit, CalendarWeekRule-Regel);

die davon ausgehen, dass Montag der erste Tag der Woche ist.

Und machen Sie System.Globalization.Calendar.GetWeekOfYear (DateTime Zeit, CalendarWeekRule Regel, DayOfWeek firstDayOfWeek); zu werfen, wenn firstDayOfWeek nicht Montag ist und Regel Iso8601 ist.

wir können alle alternativen Vorschläge auflisten und wir können das mit dem Designkomitee besprechen.

Nehmen Sie an, dass der dritte Parameter Montag sein sollte, und lösen Sie andernfalls eine Ausnahme aus – dieser Fall sieht nicht bequem aus. Ich sehe den Vorteil dieser Ausnahme nicht.
Wir könnten den dritten Parameter stillschweigend ignorieren, wenn der zweite Parameter Iso8601 ist.
Oder wir könnten den dritten Parameter mit Montag als Standard festlegen.

@iSazonov deshalb habe ich die andere Idee vorgeschlagen, die Überladung zu haben

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

die den Montag als ersten Wochentag annehmen.

Ich würde alle alternativen Designoptionen in der Beschreibung dieses Problems auflisten und dann können wir die beste davon auswählen, wenn wir sie mit dem Designkomitee besprechen.

Ich werde den Vorschlag mit Ihren Ideen aktualisieren.

@tarekgh Vorgeschlagene API aktualisiert. Fühlen Sie sich frei zu korrigieren, wenn ich etwas übersprungen habe.

Danke, @iSazonov Ich habe es ein wenig modifiziert, aber nichts am Vorschlag geändert.

Das Hinzufügen einer Iso8601Week zur Aufzählung ist eine vernünftige Idee.
Eine merkwürdige Anmerkung, die ich beobachtet habe, ist, dass einige Anwendungen die ISO-Woche wissen wollen, aber dann fragen sie Gebietsschemata/Kulturen, was ihre bevorzugte Wochenzählung ist. Welche Art funktioniert für einige Gebietsschemata, die den ISO-Wochenregeln zugeordnet sind, bricht dann aber für andere Gebietsschemata ab.

@ShawnSteele , was genau ist dein Vorschlag hier in Bezug auf deine besondere Anmerkung? Ich denke, Windows muss möglicherweise damit beginnen, die Gebietsschemata zu kennzeichnen, die ISO-Wochen benötigen, und das Framework würde diese Gebietsschemata zuordnen, um den neuen Enum-Wert zu verwenden, den wir einführen.

@tarekgh Zwei Dinge:
1) Apps, die ausdrücklich ISO-Wochenregeln wünschen, weil die App so funktioniert, benötigen wahrscheinlich GetISOWeekOfYear(). Es erscheint mir albern für eine App, die das ISO-Verhalten "braucht", um einen Kalender für eine Kultur/Sprache zu erhalten und dann zu versuchen, ihn zu korrigieren. Sie wollen explizites Verhalten, es sollte einigermaßen einfach sein.
2) Einige Kulturen beabsichtigen, ein ISO-Wochenverhalten zu haben. Das Framework sollte wahrscheinlich das ISO-Wochenregelverhalten auswählen, wenn es Windows LOCALE_IFIRSTWEEKOFYEAR von „2“ (erste Vier-Tage-Woche) sieht.

Danke, @ShawnSteele

Apps, die ausdrücklich ISO-Wochenregeln wünschen, weil die App so funktioniert, benötigen wahrscheinlich GetISOWeekOfYear()

Sie schlagen also vor, dass die neue API nicht Teil der Kalenderklasse sein sollte. es kann zum Beispiel eine statische API auf DateTimeFormInfo sein. Rechts?

Einige Kulturen beabsichtigen, ein ISO-Wochenverhalten zu haben. Das Framework sollte wahrscheinlich das ISO-Wochenregelverhalten auswählen, wenn es Windows LOCALE_IFIRSTWEEKOFYEAR von „2“ (erste Vier-Tage-Woche) sieht.

Dies sind Implementierungsdetails, wir können mehr darüber sprechen, wenn wir sie implementieren werden. Danke für die Rückmeldung.

Sie schlagen also vor, dass die neue API nicht Teil der Kalenderklasse sein sollte. es kann sich beispielsweise um eine statische API für DateTimeFormatInfo handeln. Rechts?

Das wäre wahrscheinlich angemessener, ja.

Wenn dies der Fall ist, sollten wir die alternative Designoption entfernen (die vorschlägt, der Enumeration weitere Werte hinzuzufügen). und behalten Sie nur eine Option bei, die eine statische API einführt. Wenn alle einverstanden sind, werde ich gehen und den Vorschlag entsprechend ändern.

@tarekgh - Ich denke, das hängt davon ab, was die Hauptanwendungsfälle sind. Meiner Erfahrung nach wünschen viele Apps explizit die ISO-Woche, und das kulturabhängige Verhalten ist irrelevant.

Mir ist weniger klar, ob es einen vernünftigen Anwendungsfall gibt, bei dem die Präferenz der Kultur für einen ISO-Wochenzählmechanismus für eine App interessant ist, obwohl andere Kulturen möglicherweise andere Systeme verwenden. Die Mehrheit der Apps scheint das kulturunabhängige ISO-Wochenverhalten zu wollen.

Gibt es so etwas wie ein kulturabhängiges ISO-Wochenverhalten? Macht das nicht den ganzen Sinn des Standards zunichte? :Denken:

Mir persönlich gefällt es viel besser, wohin wir jetzt gehen, als einen Aufzählungswert hinzuzufügen und nach einer Kombination von Argumenten zu suchen.

Gut, ich werde den Vorschlag aktualisieren, um die neue statische API zu haben (ich denke, dass sie in der Calendar-Klasse für die Auffindbarkeit enthalten ist) und ich werde die Enum-Vorschläge entfernen. Ich glaube, das wird viel klarer.

@khellang Das ist irgendwie mein Punkt. Einige Regionen nutzen die ISO-Woche auch als kulturelle Praxis. Manchmal herrscht dann Verwirrung darüber, ob die Software den ISO-Standard will oder für die Region gängige Praxis.

Es ist dumm, nach der Kulturversion der ISO-Woche zu fragen, aber es ist fair zu fragen, ob die Kultur die ISO-Woche standardmäßig verwendet.

Wenn wir in die Richtung gehen, halte ich es für sinnvoll, alle ISO801-Objekte und die Kompatibilität mit dem Unix-Hilfsprogramm date zu berücksichtigen.
https://en.wikipedia.org/wiki/ISO_week_date#Relation_with_the_Gregorian_calendar

• erste Woche
• letzte Woche
• Wochen pro Jahr
• Wochen pro Monat

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

• -I gibt Datum/Uhrzeit im ISO 8601-Format aus
• %g letzte zwei Ziffern des Jahres der ISO-Wochennummer (siehe %G)
• %G Jahr der ISO-Wochennummer (siehe %V); normalerweise nur mit %V sinnvoll
• %V ISO-Wochennummer, mit Montag als erstem Wochentag (01..53)

@iSazonov aktualisieren Sie den Vorschlag, wenn Sie auch die anderen Funktionen hinzufügen möchten.

@tarekgh Fertig.

Pro

```C#
// Nicht in ISO 8601 definiert, kann also entfernt werden
public static 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);

Wir fügen hier keine Formatierungs-APIs hinzu. haben Sie sich auch https://docs.microsoft.com/en-us/dotnet/standard/base-types/standard-date-and-time-format-strings angesehen , wir unterstützen bereits die ISO-Datumsformatierung. Sehen Sie sich die Spezifizierer "o" und "r" an. Ich glaube, wir sollten diese APIs aus dem Vorschlag entfernen. Wenn Sie damit einverstanden sind, aktualisieren Sie den Vorschlag bitte noch einmal, und wir können von hier aus fortfahren. Danke.

Ich stimme zu.

Was genau

```C#
public static int GetISOYearOfISOWeek(DateTime time);

```
tut? kannst du ein beispiel geben?

Entschuldigung, ich lauere hauptsächlich auf diesem Thread, aber ich wollte darauf hinweisen, dass ISO-Wochen über den Neujahrsübergang vom 31. Dezember bis zum 1. Januar zusammenhängend sind. Woche 1 des neuen Jahres kann also im Dezember des Vorjahres beginnen, oder Woche 53. Mai eines Jahres kann den 1. Januar des folgenden Jahres umfassen.

In diesen Fällen gehört die "Woche" entweder zum vorherigen oder zum nächsten Jahr, was zu einem seltsamen Verhalten führen kann, z. B. wenn der 1. Januar Teil der Woche des Vorjahres ist. Daher ist es interessant zu wissen, zu welchem ​​Jahr diese ISO-Woche gehört, zB: 1. Januar 2005 ist beispielsweise 2004-W53-6.

Wikipedia hat eine vernünftige Zusammenfassung des Verhaltens https://en.wikipedia.org/wiki/ISO_week_date

Beachten Sie, dass, wenn Sie keine ISO-Wochen zählen, das Jahr nur das gregorianische Jahr ist, sodass ein ISO-formatiertes Datum für den 1. Januar 2005 immer noch 2005-01-01 wäre - nur wenn die Wochenzahlen verwendet werden, sind die Jahre komisch werden.

"GetISOYear" ist also nicht ausreichend, da es nur beim Zählen nach ISO-Woche gilt. Ich denke, dass GetISOYearOfISOWeek ziemlich beschreibend ist und mir nichts Besseres einfällt.

Danke @shawnsteele . Ich habe das Problem zur Überprüfung bereit markiert.

Wenn ich mehr über die vorgeschlagenen APIs nachdenke, denke ich, dass es besser wäre, die ISOCalendar-Klasse einzuführen, anstatt diese statischen Methoden zur Calendar-Klasse hinzuzufügen. Ich meine, wir implementieren den vollständigen ISO-Kalender und fügen alle erforderlichen Funktionen hinzu. was denkst du darüber?

Wie ist das Gefühl bei verschachtelten Typen? Calendar.ISO.GetWeekOfYear ?

@tarekgh Wenn man bedenkt, dass der ISO-Kalender kulturunabhängig ist und die vorgeschlagenen Methoden statisch sind, sieht Ihr Vorschlag sehr gut aus und die API wird leicht auffindbar sein.

@hellang

Wie ist das Gefühl bei verschachtelten Typen? Kalender.ISO.GetWeekOfYear?

Meinen Sie, ISO wäre eine statische Klasse? Das mag in Ordnung sein, aber ich bevorzuge stattdessen die IsoCalendar-Klasse. Der Grund ist, dass ich sehe, dass ISO ein eigener Kalender ist (wie der gregorianische Kalender) und wie jeder andere Kalender verwendet werden kann. Sogar die Kalenderressourcen (der Standard, Bücher, Websites usw.) beziehen sich immer auf einen Kalender.

@iSazonov

In Anbetracht der Tatsache, dass der ISO-Kalender kulturunabhängig und die vorgeschlagenen Methoden statisch sind, sieht Ihr Vorschlag sehr gut aus und die API wird leicht auffindbar sein.

Ich stimme zu, dass es kulturunabhängig ist, aber das spielt keine Rolle, da wir bereits einige Kalender haben, die sich nicht auf bestimmte Kulturen beziehen (z. B. JulianCalendar). Das Problem der Auffindbarkeit unterscheidet sich nicht von anderen Kalendern, die wir heute unterstützen. Ich würde argumentieren, dass jeder, der sich für die ISO-Funktionalität interessiert, nach ISO-Kalender suchen würde, anstatt zu versuchen, einige Methoden der Kalenderklasse zu finden.

FWIW, ich mag die Idee von Calendar.ISO - Ähnlich wie Encoding.UTF8. Vermutlich könnte es ein ISOCalendar sein.

Es gibt jedoch immer noch GetISOYearForISOWeek(), wodurch es zusätzliche Funktionen als bei anderen Kalendern erhält.

Es lässt mich fast glauben, dass es ein weiteres ISOWeekCalendar-Formular geben muss, weil ich nicht sicher bin, was mit einem ISOCalendar passiert, wenn Sie es an Formatierungs-APIs übergeben. Woher weiß das System, dass es als 2005-01-01 (ISO-Datumsformat) oder 2004-W53-6 (ISO-Wochenformat) formatiert werden soll?

Ich mag die Idee von Calendar.ISO - Ähnlich wie Encoding.UTF8. Vermutlich könnte es sich um einen ISOCalendar handeln.

Damit brauchen wir sowieso ISOCalendar. Mit der zusätzlichen Eigenschaft Calendar.ISO können wir sie haben, wenn sie sich als wirklich nützlich erweist. Aber das haben wir bei anderen Kalendern nicht gemacht. Ich meine, wir haben zum Beispiel kein Calendar.Gregorian. Im Allgemeinen denke ich, dass es eine gute Idee sein kann, da Benutzer nicht jedes Mal ein neues Kalenderobjekt erstellen müssen, wenn sie es verwenden möchten. und stattdessen können wir die zwischengespeicherte Kalenderinstanz zurückgeben.

Es gibt jedoch immer noch GetISOYearForISOWeek(), wodurch es zusätzliche Funktionen als bei anderen Kalendern erhält.

Wir haben bereits die gleichen Fälle mit den Lunisolar-Kalendern, die mehr Methoden aufzeigen, die für diese Kalender spezifisch sind.

Es lässt mich fast glauben, dass es ein weiteres ISOWeekCalendar-Formular geben muss, weil ich nicht sicher bin, was mit einem ISOCalendar passiert, wenn Sie es an Formatierungs-APIs übergeben. Woher weiß das System, dass es als 2005-01-01 (ISO-Datumsformat) oder 2004-W53-6 (ISO-Wochenformat) formatiert werden soll?

Der ISO-Kalender wäre kulturunabhängig und wird bei der Formatierung oder Analyse überhaupt nicht verwendet. ähnlich dem julianischen Kalender.

Ja, ich meine, eine verschachtelte statische Klasse in Calendar mit ISO-spezifischen Methoden zu haben. Wie wir bereits früher in diesem Thread besprochen haben, macht es wenig Sinn, einige der vorhandenen Methoden (oder zumindest Überladungen) der vorhandenen abstrakten Klasse Calendar zu implementieren.

@hellang

Gibt es eine andere Kalender-API neben Calendar.GetWeekOfYear(DateTime time, CalendarWeekRule rule, DayOfWeek firstDayOfWeek); , die Ihrer Meinung nach für den ISO-Kalender problematisch sein wird? Ich frage, weil ich denke, dass es von Vorteil wäre, die Benutzer die ISO verwenden zu lassen, da jeder andere reguläre Kalender ein Vorteil wäre, anstatt dass Benutzer in Sonderfällen mit dem ISO-Kalender interagieren. Wir können das Verhalten von Calendar.GetWeekOfYear(DateTime time, CalendarWeekRule rule, DayOfWeek firstDayOfWeek); definieren und wir haben eine andere API Calendar.GetWeekOfYear(DateTime time);

@tarekgh Hmm , das ist ein interessanter Punkt. "CalendarWeekRule" ist in diesem Zusammenhang bedeutungslos. Was wäre das richtige Verhalten? Ignoriere es? Mach etwas anderes?

TwoDigitYearMax ist in einem ISO-Kalender bedeutungslos, da ISO vierstellige Jahreszahlen erfordert.

GetDaysInYear() für einen ISO-Wochenkalender hätte 52 oder 53 Wochentage, richtig? Das mag eigenartig sein. Und wäre anders als ein Nicht-ISO-Wochenkalender. Und ich bin mir nicht sicher, was das für die "Monate" des ISO-Wochenkalenders bedeutet, da dies in einem ISO-Wochenkalender bedeutungslose Konzepte sind. (Die Wochen sind die Monate, irgendwie)

GetLeapMonth wirft die Frage auf, ob das 52/53-Wochenjahr in einem ISO-Wochenkalender das Konzept von Schaltwochen hat?

ISO bietet das Konzept der Datumsformate in einem traditionellen Datumsformat vom 16.04.2018 oder im Format der Woche des Jahres, 2018-W16-1 – das Calendar-Objekt kann in einem DTFI.Calendar verwendet werden. Das bedeutet, dass es für die Formatierung verwendet werden könnte.

Normalerweise gibt DTFI an, wie ein Kalender formatiert ist, und der Kalender liefert die Mathematik. Das Wichtigste am ISO-Kalender ist jedoch, dass ISO die Formatierung explizit definiert (obwohl die Auflösung des Formats variieren kann). Die zulässigen Variationen betreffen die Auflösung und die einzelne Variable des ISO-Formats im Vergleich zum ISO-Wochenformat.

Jede Lösung muss wahrscheinlich die ISO/Formatierungsfrage nicht verwirren.

TwoDigitYearMax ist in einem ISO-Kalender bedeutungslos, da ISO vierstellige Jahreszahlen erfordert.

Ich glaube, das kann sich sowieso wie der gregorianische Kalender verhalten. Wenn ISO ein vierstelliges Jahr verwendet, wirkt sich TwoDigitYearMax nicht auf die App-Berechnung aus. Ich sehe hier kein wirkliches Problem.

GetDaysInYear() für einen ISO-Wochenkalender hätte 52 oder 53 Wochentage, richtig? Das mag eigenartig sein. Und wäre anders als ein Nicht-ISO-Wochenkalender. Und ich bin mir nicht sicher, was das für die "Monate" des ISO-Wochenkalenders bedeutet, da dies in einem ISO-Wochenkalender bedeutungslose Konzepte sind. (Die Wochen sind die Monate, irgendwie)

Schauen Sie sich https://en.wikipedia.org/wiki/ISO_week_date an, dort steht "

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.

Das heißt, das ISO-Jahr hat entweder 364 oder 371 Tage.

GetLeapMonth wirft die Frage auf, ob das 52/53-Wochenjahr in einem ISO-Wochenkalender das Konzept von Schaltwochen hat?

GetLeapMonth gibt immer 0 zurück, da es im ISO-Kalender kein Konzept für einen Schaltmonat gibt.
IsLeapDay und IsLeapMonth geben immer false zurück. IsLeapYear kann jedoch true für die Jahre zurückgeben, die 371 Tage haben.

ISO bietet das Konzept der Datumsformate in einem traditionellen Datumsformat vom 16.04.2018 oder im Format der Woche des Jahres, 2018-W16-1 – das Calendar-Objekt kann in einem DTFI.Calendar verwendet werden. Das bedeutet, dass es für die Formatierung verwendet werden könnte.
Normalerweise gibt DTFI an, wie ein Kalender formatiert ist, und der Kalender liefert die Mathematik. Das Wichtigste am ISO-Kalender ist jedoch, dass ISO die Formatierung explizit definiert (obwohl die Auflösung des Formats variieren kann). Die zulässigen Variationen betreffen die Auflösung und die einzelne Variable des ISO-Formats im Vergleich zum ISO-Wochenformat.
Jede Lösung muss wahrscheinlich die ISO/Formatierungsfrage nicht verwirren.

Der ISO-Kalender wird keiner Kultur zugeordnet (ähnlich wie Julianische und Lunisolar-Kalender). Die Formatierung mit diesem Kalender wäre also ohnehin kein Problem.

Für Calendar.GetWeekOfYear(DateTime time, CalendarWeekRule rule, DayOfWeek firstDayOfWeek); können wir das Verhalten erzwingen, indem wir die Parameter CalendarWeekRule und DayOfWeek ignorieren. Außerdem führen wir die neue Überladung Calendar.GetWeekOfYear(DateTime time) zur logischen Verwendung ein. Natürlich dokumentieren wir das Verhalten beider Methoden und können erklären, warum sich diese so verhalten.

Ich dränge nicht wirklich darauf, ISOCalendar zu haben, ich sehe nur, dass die Leute im Internet und in Büchern (z. B. Kalenderberechnungen) immer auf die ISO-Berechnung als ISO-Kalender verweisen. Deshalb dachte ich, es wäre sinnvoll, es als eigenen Kalender zu haben, anstatt einige statische Methoden als Hilfsfunktionen zu haben.

Wenn Sie immer noch sehen, dass dies verwirrend ist, bin ich in Ordnung, weitere @khellang- Vorschläge zu untersuchen oder beim letzten Vorschlag zu bleiben.

Das heißt, das ISO-Jahr hat entweder 364 oder 371 Tage.

Richtig, was ich meinte, war, dass ein .ISO-Kalender kein .ISOWeek-Kalender wäre. Wenn es nur für Berechnungen verwendet wird, brauchen wir nur einen .ISOWeek-Kalender (nicht den .ISO-Kalender) - aber wenn der ISO-Kalender später hinzugefügt würde, wäre das seltsam.

GetLeapMonth gibt immer 0 zurück, da es im ISO-Kalender kein Konzept für einen Schaltmonat gibt.

In einem ISO-Kalender gibt es einen Schaltmonat. In einem ISO-Wochenkalender gibt es keinen Schaltmonat. (Es sei denn, Sie haben die Monatszugriffsmethoden verwendet? Planen Sie, GetMonth() und dergleichen zu deaktivieren?)

Ich denke, dass ein "ISO-Kalender" und ein "ISO-Wochenkalender" aus Sicht der Formatierung sinnvoll sind - aber Sie können ein DTFI erstellen, das weiß, wie ISO-Kalender mit jedem gregorianischen Kalender formatiert werden.

Ich denke auch, dass das Hinzufügen dieser als expliziten Kalender oder zwei an der Oberfläche sinnvoll erscheint, aber zu vielen seltsamen Fragen und möglicherweise unerwartetem Verhalten führt. Oder Zusatzwünsche.

Also lehne ich mich zurück und füge dem gregorianischen Kalender die beiden Methoden hinzu: GetISOWeek() und GetIsoYearOfIsoWeek() (oder GetIsoWeekYear()?) – das würde das unmittelbare Problem lösen, ohne ein paar andere seltsame Verhaltensweisen zu verursachen.

Also lehne ich mich zurück und füge dem gregorianischen Kalender die beiden Methoden hinzu: GetISOWeek() und GetIsoYearOfIsoWeek() (oder GetIsoWeekYear()?) – das würde das unmittelbare Problem lösen, ohne ein paar andere seltsame Verhaltensweisen zu verursachen.

Was ist der Vorteil, wenn diese Methoden für den gregorianischen Kalender und nicht für die abstrakte Kalenderklasse verwendet werden? oder wie @khellang vorgeschlagen hat, eine statische ISO-Klasse in der Kalenderklasse zu haben (dh Calendar.ISO.GetISOWeek)?

Ich hatte angenommen, dass Calendar.ISO ein "vollständiger" ISOCalendar wäre. Aber wenn es nur ein paar Methoden sind, würde das funktionieren, denke ich,

ISO wäre eine statische Klasse

```C#
Namespace System.Globalization
{
öffentlicher abstrakter Klassenkalender: ICloneable
{
öffentliche statische Klasse ISO
{
public static int GetISOWeekOfYear(DateTime time);
public static int GetISOFirstWeekOfYear(DateTime time);
public static int GetISOLastWeekOfYear(DateTime Zeit);
public static int GetISOWeeksPerYear(DateTime time);
public static 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);
    }
}

Ich aktualisiere den Vorschlag so, dass er die Klasse Calendar.ISO enthält, und liste den ursprünglichen Vorschlag als alternatives Design auf.

@iSazonov Wenn Sie damit einverstanden sind, könnten Sie den Vorschlag aktualisieren? oder ich kann es tun, wenn Sie nichts dagegen haben, den Vorschlag zu ändern.

Und sobald Sie eine statische Calendar.ISO -Klasse haben, können Sie alle Prä- und Suffixe von ISO aus den Methodennamen streichen 😊

@tarekgh Fühlen Sie sich frei zu aktualisieren - der Vorschlag LGTM.

fertig!

Ich habe Tippfehler in den Kommentaren ISO 801 -> ISO 8601 behoben

Hier noch eine Frage bzgl.

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

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);

Entschuldigung, ich habe nicht mitverfolgt :)
Diese klingen für mich schlecht. Der "Kalender" hat eine Wocheneinstellung, die NICHT die ISO-Woche ist. Wenn dies also die ersten/letzten ISO-Wochen sein sollen, sollten sie den ISO-Wochenkalender angeben.

Keine Ahnung, wie interessant die "erste Iso-Woche" wäre, das ist immer "1", oder? Und die letzte Woche wäre wie "GetLastISOWeekOfYear" - was ein bisschen interessant sein könnte.

Der Beginn/das Ende des ISO-Jahres erscheinen mir interessant, da sie selten der 1. Januar sind. Sie können auch die Woche # von diesem Datum erhalten, wenn Sie die letzte ISO-Woche # des Jahres wollen.

IsoWeeksPerYear ändert sich (52/53), daher erscheint „Pro“ seltsam. Es gibt 16 oz pro Quart (für jeden Quart). IsoWeeksInYear?

GetIsoWeeksInYear ist dasselbe wie die letzte ISO-Woche des Jahres, daher würde ich es vorziehen, wenn die erste/letzte wegfällt, sie sind überflüssig.

Ich mag die Idee eines:
public static DateTime GetISOWeekYearStart(DateTime time);
öffentlich statisch DateTime GetISOWeekYearEnd(DateTime time);

Genau das habe ich mich gefragt, was der Vorteil von GetFirstWeekOfYear und GetLastWeekOfYear ist. so sieht es für mich aus diese wirklich nicht benötigt.

Warum möchten Sie nicht die DateTime zurückgeben, die auf den Anfang und das Ende eines Jahres zeigt? Ich fühle mich nicht stark dabei, aber gleichzeitig sehe ich den Vorteil, diese Daten zu haben. Stellen Sie sich vor, Sie haben ein Kalendersteuerelement, das den Beginn und das Ende der ISO-Jahre markieren kann. Beachten Sie, dass wir den Namen solcher APIs in etwas wie GetYearStart und GetYearEnd ändern können.

Du hast mich verwirrt. Ich sagte:

Ich mag die Idee eines:
public static DateTime GetISOWeekYearStart(DateTime time);
öffentlich statisch DateTime GetISOWeekYearEnd(DateTime time);

Offensichtlich müssten sie das "ISOWeek"-Bit angeben, da es sich nur um den ISO-Kalender handelt.

Entschuldigung, ich habe es falsch verstanden als "mag ich nicht".

Was ist mit der Namensgebung:

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

Diese Benennung ist unzureichend.
Ein "ISO"-Kalender ist genau wie der gregorianische Kalender, den wir alle kennen. Es beginnt am 01.01.2018 und endet am 31.12.2018. Es hat 365/366 Jahre.
In dieser Diskussion dreht sich alles um den ISO-Wochenkalender, der anders ist.

Also sollte die Klasse entweder "ISOWeek" heißen oder die Methoden müssen dies angeben.

@ShawnSteele sieht aus, als hätten Sie diese Methoden verpasst, die sich bereits in der ISO-Klasse befinden.

Wäre Calendar.ISO.GetYearStart/GetYearEnd. oder anderer Vorschlag ist

Kalender.ISO.GetFirstWeekStart/GetLastWeekEnd

Nein, das ist mir nicht entgangen. "ISO" spezifiziert viele verschiedene Dinge über Datumsformate. „ISO“ bedeutet nicht, dass es sich um das ISO-Wochen-Jahres-Format handeln MUSS.

Entweder sollte die Klasse ISOWeek heißen, oder die Variante „Week“ muss in der Methode angegeben werden.

zB: Kalender.ISOWeek.GetYearStart/GetYearEnd

Calendar.ISO.GetYearStart ist mehrdeutig. Ich würde erwarten, dass dies immer der 1. Januar ist, nicht der Jahresbeginn der ISO-Woche

warum ist Calendar.ISO.GetFirstWeekStart/GetLastWeekEnd nicht ok?

Das setzt voraus, dass die "erste Woche", von der Sie sprechen, eine ISO-Woche ist. Was für Leute, die das ISO-Wochenkalendersystem verstehen, eine vernünftige Annahme zu sein scheint, aber ich denke, es könnte für andere etwas mehrdeutig sein.

Ich mag den ISOWeek-Namen nicht, weil die anderen API-Namen darin keinen Sinn machen würden. ISOWeek.GetWeekOfYear hätte beispielsweise einen redundanten „Week“-Namen. Wenn Sie der Meinung sind, dass „Calendar.ISO.GetFirstWeekStart/GetLastWeekEnd“ mehrdeutig sein kann, können wir „Calendar.ISO.GetYearStart/GetYearEnd“ verwenden

Die anderen Methoden verwenden "ISOWeek"? Also Kalender.ISO.GetFirstISOWeekStart?

GetYearStart/End finde ich weniger umständlich, aber sie müssten ISOWeek enthalten. GetISOWeekYearStart/End - was sie umständlicher machen würde.

Die anderen Methoden verwenden "ISOWeek"? Also Kalender.ISO.GetFirstISOWeekStart?

Nein, tun wir nicht. Schauen Sie sich den Vorschlag oben auf der Seite an und wir haben:

```C#
Namespace System.Globalization
{
öffentlicher abstrakter Klassenkalender: ICloneable
{
öffentliche statische Klasse ISO
{
// Alle ISO 8601-Objekte (https://en.wikipedia.org/wiki/ISO_week_date#Relation_with_the_Gregorian_calendar)
public static int GetWeekOfYear (DateTime Zeit);
public static int GetFirstWeekOfYear(DateTime time);
public static int GetLastWeekOfYear (DateTime Zeit);
public static int GetWeeksPerYear(DateTime Zeit);

       // 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);
}

}
```

Was ist mit ISO.GetWeekYearStart/End?

Ich finde "GetIsoFirstWeekStart" ungeschickt. Sie möchten wirklich den Beginn/das Ende des ISO-Wochenjahres. Was zufällig der Beginn der ersten Woche ist, aber das ist eine zusätzliche unnötige mentale Umleitung.

GetYearStart an sich ist mehrdeutig, weil es nicht sagt, ob es sich um das Kalenderjahr oder das Wochenjahr handelt.

Was ist mit ISO.GetWeekYearStart/End?

Das sieht für mich vernünftig aus. Ich werde den Vorschlag entsprechend aktualisieren, wenn sonst niemand etwas dagegen hat :-)

Würde dies für GetWeekYearEnd den Beginn der letzten Woche im Jahr zurückgeben? oder wird am letzten Tag der Woche des Jahres zurückkehren?

Ich würde Anfang/Ende des Jahres zurückgeben. (letzter Wochentag des Jahres für GetWeekYearEnd)

Ich habe gefragt, weil es nach der Woche des Jahresendes fragt :-) Ich denke, dies kann so verstanden werden, dass der erste Tag der Woche zurückgegeben wird, die das Jahr beendet. Die Verwirrung, die ich jetzt sehe, ist, ob die API klar ist, ob wir die Woche oder den Tag zurückgeben?

Ich fing an zu denken, dass GetYearStart/End klarer wäre :-)

zu deinem kommentar

GetYearStart an sich ist mehrdeutig, weil es nicht sagt, ob es sich um das Kalenderjahr oder das Wochenjahr handelt.

Dies ist klar, da der Aufruf ein ISO-Wort (z. B. ISO.GetYearStart) enthält, das den Jahresbeginn des ISO-Jahres angibt. Ich sehe nicht, dass dies wirklich zweideutig ist.

Ich würde erwarten, dass ISO.GetYearStart() den 1. Januar und ISO.GetYearEnd() den 31. Dezember zurückgibt. Dies ist der Unterschied zwischen einem ISO-Jahr und einem ISO-Wochenjahr.

Wir haben offline mit @ShawnSteele gesprochen und hier ist der endgültige Vorschlag, auf den wir uns geeinigt haben, der jegliche Verwirrung beseitigen sollte.

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); } }

Lassen Sie mich wissen, wenn jemand Bedenken bezüglich des Vorschlags hat, damit ich den Vorschlag oben auf der Seite aktualisieren kann.

LGTM.

Ja, das sieht gut aus. Wäre es sinnvoll, auch Methoden zum Formatieren eines ISO-Wochendatums als Zeichenfolge einzubeziehen?

Aus Wikipedia:

Ein genaues Datum wird durch das ISO- Wochennummerierungsjahr im Format YYYY, eine Wochennummer im Format ww mit dem Präfix „W“ und die Wochentagnummer , eine Ziffer d von 1 bis 7, die mit Montag beginnt und endet, angegeben mit Sonntag. Beispielsweise entspricht das gregorianische Datum 31. Dezember 2006 dem Sonntag der 52. Woche des Jahres 2006 und wird 2006-W52-7 (in erweiterter Form) oder 2006W527 (in kompakter Form) geschrieben.

Gibt es einen Grund, warum GetWeeksPerYear , GetYearStart und GetYearEnd nicht einfach int year nehmen können?

Die vorhandenen Methoden auf Calendar verwenden ein anderes Namensschema; GetDaysInYear , GetDaysInMonth und GetMonthsInYear . Sollte GetWeeksPerYear GetWeeksInYear sein?

Ja, das sieht gut aus. Wäre es sinnvoll, auch Methoden zum Formatieren eines ISO-Wochendatums als Zeichenfolge einzubeziehen?

Im Allgemeinen erfolgt die Formatierung über die Kulturklassen (z. B. DateTimeFormatInfo), aber bisher unterstützen wir keine Kultur, die diese Formatierung benötigt. Wir denken vielleicht, dass wir später eine ähnliche Bereitstellung wie für die ISO-Formatierung (dh das "o"-Format) in Betracht ziehen, die YYYY-Wnn-dd (oder YYYYWnndd) unterstützen kann. Ich mache das gerne getrennt von diesem Vorschlag.

Gibt es einen Grund, warum GetWeeksPerYear, GetYearStart und GetYearEnd nicht einfach ein Jahr annehmen können?

Darüber habe ich schon einmal nachgedacht, ich denke, Benutzer würden die ISO-Woche in Verbindung mit dem gregorianischen Kalender verwenden. Daher glaube ich, dass die Leute in Hauptszenarien mit DateTime beginnen würden, und deshalb ziehe ich es vor, dass diese APIs DateTime und nicht die Jahreszahl verwenden. lass es mich wissen, wenn du anders denkst.
Außerdem haben Sie mich an ein anderes Szenario denken lassen, das wir meiner Meinung nach unterstützen müssen, nämlich das Abrufen der gregorianischen DateTime aus dem ISO-Datum. etwas wie:

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

Ich denke, dies ist wichtig, um die Konvertierung von ISO nach Gregorianisch flexibel zu gestalten. So können die Leute alle Daten hin- und zurückfahren. Wenn Sie damit einverstanden sind, füge ich dies auch dem Vorschlag hinzu.

Die vorhandenen Methoden im Kalender verwenden ein anderes Benennungsschema. GetDaysInYear, GetDaysInMonth und GetMonthsInYear. Sollte GetWeeksPerYear aus Konsistenzgründen stattdessen GetWeeksInYear sein?

Das ist ein guter Punkt. Ich aktualisiere den API-Namen auf GetWeeksInYear. danke für den fang.

Sollte das nicht DayOfWeek day statt int day ? Es ist effektiv "Berechnen eines Datums anhand des Jahres, der Wochennummer und des Wochentags", das auf Wikipedia beschrieben wird

Ich glaube, dass die Leute in Hauptszenarien mit DateTime beginnen würden, und deshalb ziehe ich es vor, dass diese APIs DateTime und nicht die Jahreszahl verwenden. lass es mich wissen, wenn du anders denkst.

Ich habe versucht, die Methoden im aktuellen Vorschlag umzusetzen, und die oben genannten Methoden benötigen nur ein gregorianisches Jahr. Es ist wirklich mühsam, wenn Sie ein ganzes DateTime (mit Monat und Tag) konstruieren müssen, nur um das Start- oder Enddatum des Jahres zu erhalten.

Sollte das nicht der DayOfWeek-Tag statt des Int-Tags sein?

Ich werde den Vorschlag damit aktualisieren. Sie haben Recht, der Tag sollte zwischen Sonntag, Montag .... Samstag liegen

Ich habe versucht, die Methoden im aktuellen Vorschlag umzusetzen, und die oben genannten Methoden benötigen nur ein gregorianisches Jahr. Es ist wirklich mühsam, wenn Sie eine ganze DateTime (mit Monat und Tag) konstruieren müssen, nur um das Start- oder Enddatum des Jahres zu erhalten.

Das Problem, auf das die Leute, fürchte ich, stoßen werden, ist das Eingabejahr, ist es wirklich das gregorianische Jahr? oder ist es ISO Jahr. Sie wissen, dass wir einige Daten in Gregorianisch (um den 29. Dezember) erhalten können, die zum nächsten Jahr in ISO gehören können. Mit DateTime wird diese Verwirrung beseitigt, und die Monats- und Tagesnummer in DateTime ist auch sehr wichtig, um die Datumszuordnung zu dem ISO-Jahr zu kennen. Der andere Vorschlag wäre, nur die Jahreszahl zu akzeptieren, die das ISO-Jahr und nicht das gregorianische Jahr ist, und wir können den Parameter als isoWeekYear bezeichnen.

Meine letzte Antwort war nur bzgl

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

aber ich glaube immer noch, dass das Zurücksetzen eine DateTime und nicht nur ein Jahr dauern muss.

Die Monats- und Tagesnummer in DateTime ist auch sehr wichtig, um die Datumszuordnung zu dem ISO-Jahr zu kennen.

Bei einigen der Methoden ist es wichtig, ja, aber nicht bei den, die ich erwähnt habe. Die einzige Information, die benötigt wird, ist ein gregorianisches Jahr. Es ist trivial, DateTime.Year zu übergeben, wenn Sie bereits eine DateTime -Instanz haben, aber es ist völlig unnötig, eine DateTime zu erstellen (welche Werte verwende ich für Monat und Tag? spielt das eine Rolle ? werden sie verwendet?), nur um sie weiterzugeben.

Übrigens gibt es bereits einen Präzedenzfall für die Verwendung int year in Calendar.GetDaysInYear . Wir könnten genauso gut konsequent sein.

Ich kann meine schnellen Implementierungen zusammenfassen, damit Sie ein Gefühl für die APIs und ihre Verwendung bekommen, wenn Sie möchten?

Bei einigen der Methoden ist es wichtig, ja, aber nicht bei den, die ich erwähnt habe. Die einzige Information, die benötigt wird, ist ein gregorianisches Jahr. Es ist trivial, DateTime.A year zu übergeben, wenn Sie bereits eine DateTime-Instanz haben, aber es ist völlig unnötig, eine DateTime zu erstellen (welche Werte verwende ich für Monat und Tag? Spielt das eine Rolle? Werden sie verwendet?), nur um sie zu übergeben.

Was passiert, wenn Sie ein gregorianisches Jahr haben, das 2 ISO-Jahre kreuzt? Hier das Beispiel,

So. 28. Dez. 2008 | 2008-W52-7
Mo, 29. Dez. 2008 | 2009-W01-1

Wenn Sie also 2008 an unsere APIs übergeben, wird es zweideutig sein. Aus diesem Grund habe ich erwähnt, dass die APIs DateTime oder die ISO-Jahreszahl und nicht die gregorianische Zahl annehmen müssen.

Übrigens gibt es bereits einen Präzedenzfall für die Verwendung von int year in Calendar.GetDaysInYear. Wir könnten genauso gut konsequent sein.

Ich fühle mich nicht stark, weil diese API nur 7 * GetWeeksInYear (...) zurückgibt.

Ein weiterer Hinweis zur Verwendung von DayOfWeek für den Tag anstelle von int in der folgenden API
C# public DateTime ToDateTime(int year, int week, int day);

Die ISO-Woche verwendet normalerweise Tage von 1 bis 7, während DayOfWeek Tage von Sonntag = 0 bis Samstag = 6 hat. Glauben Sie, dass dies Verwirrung stiften kann? Wenn wir DayOfWeek verwenden, glauben Sie, dass wir Werte wie (DayOfWeek) 7 akzeptieren?

Noch etwas zu den folgenden 2 APIs

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

sollen wir sie einfach GetWeek und GetYear nennen? Diese werden als ISOWeek.GetWeek(...) und ISOWeek.GetYear(...) geschrieben.

Vielleicht ist es sinnvoll zu haben:
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);

Die ISO-Woche verwendet normalerweise Tage von 1 bis 7, während DayOfWeek Tage von Sonntag = 0 bis Samstag = 6 hat. Glauben Sie, dass dies Verwirrung stiften kann?

Nein überhaupt nicht. Wir haben bereits eine Aufzählung, die den Wochentag darstellt. Es wäre schade, wenn wir es nicht nutzen würden. Warum sollten wir hier einen weniger spezifischen Typ verwenden, aber einen spezifischeren Typ ( DateTime ) in GetWeeksInYear , GetYearStart und GetYearEnd ?
Ich bezweifle, dass es jemanden interessiert, ob Sunday 0 , 1 , 6 oder 7 darstellt. Sie wollen nur Sonntag, das war's. Die API sollte für die Konvertierung in die korrekte numerische Darstellung verantwortlich sein.

Wenn wir DayOfWeek verwenden, glauben Sie, dass wir Werte wie (DayOfWeek) 7 akzeptieren?

Ich würde nein sagen. Was würde es darstellen? Gehen wir davon aus, dass sie den Sonntag wollen?

sollen wir sie einfach GetWeek und GetYear nennen?

Ja, einverstanden 👍

Was passiert, wenn Sie ein gregorianisches Jahr haben, das 2 ISO-Jahre kreuzt? Hier das Beispiel,

So. 28. Dez. 2008 | 2008-W52-7
Mo, 29. Dez. 2008 | 2009-W01-1

Wenn Sie also 2008 an unsere APIs übergeben, wird es zweideutig sein. Aus diesem Grund habe ich erwähnt, dass die APIs DateTime oder die ISO-Jahreszahl und nicht die gregorianische Zahl annehmen müssen.

Ich denke immer noch, dass Sie dies mit den anderen Methoden verwechseln, die tatsächlich den Monat und das Datum benötigen .

Dies wäre das Ergebnis, wenn Sie 2008 an die verschiedenen Methoden übergeben:

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

Und nur der Vollständigkeit halber, das würde Ihnen 2009 geben:

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

GetWeeksInYear gibt immer die Anzahl der Wochen im angegebenen Jahr zurück. Egal welcher Monat und Tag es ist. Dieser Kalender sitzt immer noch über dem gregorianischen Kalender.
GetYearStart und GetYearEnd geben das gregorianische Start- und Enddatum für das angegebene ISO-Wochenjahr zurück.

Können Sie ein Beispiel nennen, bei dem ein Monat und ein Tag diese Ergebnisse tatsächlich verändern würden?

Hier ist ein Überblick mit meiner aktuellen Implementierung:

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

@hellang

Ich würde nein sagen. Was würde es darstellen? Gehen wir davon aus, dass sie den Sonntag wollen?

Ja. Das Szenario in meinem Kopf ist, dass jemand ein ISO-Datum von einer Quelle bekommt (die die Tage von 1..7 haben wird) und dann einfach das Framework mit aufrufen möchte. Wenn wir 7 nicht als Sonntag behandelt haben, muss der Anrufer dies tun (Tag % 7), bevor er uns anruft.

Ich denke immer noch, dass Sie dies mit den anderen Methoden verwechseln, die tatsächlich den Monat und das Datum benötigen.

Ich glaube, ich bin nicht verwirrt, oder vielleicht bin ich immer noch verwirrt :-)
Aus Ihrem Beispiel geht hervor, dass Sie mit der Erwähnung von 2008 gemeint haben, dass 2008 das ISO-Jahr und nicht das gregorianische Jahr ist. Das habe ich versucht zu sagen, dass die APIs die ISO-Jahresnummer verwenden. Schauen Sie sich meinen vorherigen Kommentar an, in dem ich or it has to take the ISO year number and not the Gregorian number. sagte.

Beispielsweise:

Jemanden zu haben, der DateTime hat und nur DateTime.Year an die APIs weitergibt, wäre die falsche Annahme. und sie müssen so etwas tun:

```C#
DateTime dt = new DateTime (2008, 12, 29);
DateTime yearStart = ISOWeek.GetYearStart(ISOWeek.GetYear(dt)); // ISOWeek.GetYear(dt) gibt 2009 und nicht 2008 zurück.

This will return a different value than if you calling 

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

Übersehe ich hier etwas? aber wenn dies Ihren Vorstellungen entspricht, dann ist es in Ordnung, wenn die APIs nur die Jahreszahl verwenden, und wir müssen klarstellen, dass diese Jahreszahl die ISO-Jahreszahl und nicht die gregorianische Jahreszahl ist. Vielleicht können wir den Parameter als isoYear oder so bezeichnen.

Ich habe mir deinen Code nicht angesehen, aber ich werde es mir bei der ersten Gelegenheit ansehen.

@iSazonov

Ich denke, zu haben

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

reicht hier. Ich sehe nicht, dass die dort vorgeschlagenen Überladungen benötigt werden.

aber wenn dies Ihren Vorstellungen entspricht, dann ist es in Ordnung, wenn die APIs nur die Jahreszahl verwenden, und wir müssen klarstellen, dass diese Jahreszahl die ISO-Jahreszahl und nicht die gregorianische Jahreszahl ist.

Gibt es überhaupt einen Unterschied zwischen einem "ISO-Wochenjahr" und einem "gregorianischen Jahr"? Ich weiß, dass sie an unterschiedlichen Daten beginnen und enden, aber 2009 im gregorianischen Kalender ist 2009 im ISO-Wochenkalender, richtig? Es ist nur verwirrend, wenn Sie anfangen, Monate und Tage einzubeziehen.

Zumindest ISOWeek.GetYearStart(ISOWeek.GetYear(dt)) lässt sich gut komponieren.

Ich bin mir nicht sicher, ob es mehr oder weniger verwirrend wäre, es year oder isoYear zu nennen 😂

Ich bin mir nicht sicher, ob die Bezeichnung year oder isoYear es mehr oder weniger verwirrend machen würde

Wenn Sie glauben, dass die Verwirrung weiterhin bestehen wird, behalten wir möglicherweise den ursprünglichen Vorschlag bei, DateTime anstelle des Jahres zu übergeben. zu diesem Zeitpunkt würde es keine Verwirrung geben.

Die andere Idee kann eine Überladung für diese APIs sein, eine nimmt DateTime und die andere Überladung nimmt das Jahr, wie Sie vorgeschlagen haben. Ich ziehe es immer noch vor, den Parameter für diese Überladung als isoYear zu bezeichnen.

Ich habe nur wirklich Mühe zu verstehen, wie es es weniger verwirrend macht. Es zwingt Sie dazu, redundante Eingaben zu machen, während Sie immer noch dieselbe Jahreszahl eingeben. In meinen Augen ist das nicht nur genauso verwirrend, sondern auch mehr Arbeit ohne Nutzen.

Lassen Sie uns weitermachen und den APIs-Vorschlag bestätigen, dem wir uns, denke ich, jetzt alle einig sind:

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); } }

klingt das richtig?

Sollte ToDateTime() ToGregorianDateTime() sein?

Wie adressiere ich "%G Jahr der ISO-Wochennummer (siehe %V); normalerweise nur mit %V sinnvoll"? Sollten wir die Überladung hinzufügen:
c# public static int GetYearOfWeek(int isoYear, int isoWeek);

klingt das richtig?

Ja! Danke, @tarekgh ♥️

Entschuldigung, ich war ein paar Tage unterwegs.

Ich mag den "DayOfWeek" nicht besonders. ISO-Wochenkalender haben Wochen, die den Monaten eines traditionellen gregorianischen Kalenders entsprechen, und die Nummer des Wochentags ist ähnlich der Nummer des Monats in einem normalen Kalender. Es formatiert also Dinge wie 2018-W12-7. Wir wissen zufällig, welchem ​​"Tag" diese 7 entspricht, aber das ISO-Wochenformat gibt Tagesnummern an. Sicher, .Net hat eine DayOfWeek-Klasse, aber das scheint mir zu einer unnötigen Manipulation der Werte zu führen.

Ich mag auch die Nomenklatur "isoYear" nicht besonders. "Iso-Jahr" ist kein Ding. ISO spezifiziert die Formatierung von Datumsangaben in einer eindeutigen traditionellen Jahr-Monat-Tag-Form oder optional in einer Jahr-Wochen-Tag-Form. "Jahr" ist ein gültiges ISO-Konzept für beide Systeme. (Und sogar zusätzliche Systeme). In der Tat gibt die ISO ausdrücklich eine Anleitung für traditionelle gregorianische Jahreszahlen an, z. B. die Forderung, dass sie 4-stellig sein müssen, um Verwirrung im Jahr 2000 zu vermeiden. An sich könnte „Iso Year“ auf beides zutreffen, obwohl die Leute manchmal „Iso Week Calendar Year“ abkürzen, was eine irreführende Konvention ist.

Die Tatsache, dass es sich bei dieser Klasse um die IsoWeek-Klasse handelt, sollte ausreichen, um festzustellen, dass mit "Jahr" ein ISO-Wochenkalenderjahr gemeint ist. Wenn IsoWeek immer noch zu zweideutig ist, würde ich "IsoWeekCalendar" vorschlagen, um die Verwirrung weiter zu verringern. Wenn „iso“ als notwendig empfunden wird, warum dann nicht auch „isoWeek“ und „isoDay“? Insbesondere „Woche“ hat genau denselben Qualifizierer, dass dies eine Woche im Iso-Wochenkalender ist und nicht irgendeine andere Woche.

@ShawnSteele Danke, dass du dich noch einmal gemeldet hast!

Sicher, .Net hat eine DayOfWeek-Klasse, aber das scheint mir zu einer unnötigen Manipulation der Werte zu führen.

Ich denke nicht, dass wir uns zu sehr auf die Werte festlegen sollten. Die Aufzählung bietet eine Möglichkeit, "Wochentag" darzustellen, und wird bereits in allen .NET-Kalender-/Datums-/Uhrzeit-APIs verwendet. Wir sollten zumindest eine Überladung damit bereitstellen, damit es nahtlos mit den anderen APIs funktioniert.

„isoYear“-Nomenklatur. "Iso-Jahr" ist kein Ding. ISO spezifiziert die Formatierung von Datumsangaben in einer eindeutigen traditionellen Jahr-Monat-Tag-Form oder optional in einer Jahr-Wochen-Tag-Form. "Jahr" ist ein gültiges ISO-Konzept für beide Systeme. (Und sogar zusätzliche Systeme). In der Tat gibt die ISO ausdrücklich eine Anleitung für traditionelle gregorianische Jahreszahlen an, z. B. die Forderung, dass sie 4-stellig sein müssen, um Verwirrung im Jahr 2000 zu vermeiden. An sich könnte „Iso Year“ auf beides zutreffen, obwohl die Leute manchmal „Iso Week Calendar Year“ abkürzen, was eine irreführende Konvention ist.

Die Tatsache, dass es sich bei dieser Klasse um die IsoWeek-Klasse handelt, sollte ausreichen, um festzustellen, dass mit "Jahr" ein ISO-Wochenkalenderjahr gemeint ist. Wenn IsoWeek immer noch zu zweideutig ist, würde ich "IsoWeekCalendar" vorschlagen, um die Verwirrung weiter zu verringern. Wenn „iso“ als notwendig empfunden wird, warum dann nicht auch „isoWeek“ und „isoDay“? Insbesondere „Woche“ hat genau denselben Qualifizierer, dass dies eine Woche im Iso-Wochenkalender ist und nicht irgendeine andere Woche.

Ja, deswegen habe ich gesagt:

Gibt es überhaupt einen Unterschied zwischen einem "ISO-Wochenjahr" und einem "gregorianischen Jahr"? Ich weiß, dass sie an unterschiedlichen Daten beginnen und enden, aber 2009 im gregorianischen Kalender ist 2009 im ISO-Wochenkalender, richtig? Es ist nur verwirrend, wenn Sie anfangen, Monate und Tage einzubeziehen.

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

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);

Wäre es sinnvoll, Überladungen hinzuzufügen, die DateTimeOffset anstelle von DateTime akzeptieren, um diese Methoden für Personen, die sich um Zeitzonen kümmern müssen, einfacher zu verwenden?

Was würden die Implementierungen mit den zusätzlichen Informationen (dem UTC-Offset) machen?

@hellang

Was würden die Implementierungen mit den zusätzlichen Informationen (dem UTC-Offset) machen?

Ich denke, dasselbe würden die DateTime -Überladungen mit DateTimeKind oder TimeOfDay tun: ignorieren.

Ich denke, dasselbe würden die DateTime-Überladungen mit DateTimeKind oder TimeOfDay tun: ignorieren.

Läuft das nicht auf das gleiche Problem hinaus, wenn Sie eine DateTime übergeben müssen, wenn Sie nur an der Year -Eigenschaft interessiert sind?

Wenn .NET einen reinen Date -Typ hätte, würden diese Überladungen idealerweise nur diesen annehmen.

Es ist ganz einfach, von DateTimeOffset zu DateTime zu wechseln, wenn das alles ist, was Sie brauchen, oder?

@hellang

Es ist ganz einfach, von DateTimeOffset zu DateTime zu wechseln, wenn das alles ist, was Sie brauchen, oder?

Es ist. Ich habe mich nur gefragt, ob es sich lohnen würde, die Arbeit mit DateTimeOffset etwas bequemer zu machen. Auf diese Weise werden die Leute nicht entmutigt, DateTimeOffset zu verwenden, wenn sie es verwenden sollten.

Auf diese Weise werden die Leute nicht entmutigt, DateTimeOffset zu verwenden, wenn sie es verwenden sollten.

Ich bin dafür, die Verwendung von DateTimeOffset zu fördern (wenn Sie es brauchen), aber in Bezug auf die Konsistenz und die Anzahl der Überladungen bin ich mir nicht sicher, ob es sich lohnt. Jedenfalls habe ich hier keine starke Meinung. Ich bin mir sicher, dass die API-Rezensenten einige gute Argumente dafür oder dagegen haben werden.

Beim DateTimeOffset-Problem sehe ich nicht, dass ISOWeek irgendetwas mit Zeitzonen oder mit der Zeit im Allgemeinen macht. Es verarbeitet hauptsächlich das Datum und nicht die Uhrzeit. Ich glaube also nicht, dass wir DateTimeOffset verwenden müssen.

Für das DayOfWeek-Problem verwende ich gerne den expliziten Typ als DayOfWeek, und wir können immer noch zulassen, dass der Wert 7 auch als Sonntag übergeben wird. Auf diese Weise sollte es kein Problem geben, wenn uns jemand mit Werten von 1..7 (mit Casting auf DayOfWeek) anrufen muss oder jemand uns mit DayOfWeek Sunday..Saturday anrufen möchte. Ich mag es nicht, die Überladung zu haben, die eine Wochentagnummer anstelle von DayOfWeek benötigt.

Beim ISO-Jahr sehe ich immer noch den Unterschied zwischen dem gregorianischen Jahr und dem ISO-Jahr. Offensichtlich kann das ISO-Jahr zu einer anderen Zeit als dem gregorianischen Jahr beginnen. Das ISO-Jahr kann eine andere Länge (Anzahl Tage oder Wochen) haben als das gregorianische Jahr. Es ist genug Unterschied, um zu unterscheiden, ob wir davon ausgehen, dass der Eingabeparameter das gregorianische Jahr oder das ISO-Jahr ist. Anzunehmen, dass das ISO-Jahr ein gregorianisches Jahr ist, ist eine sehr falsche Annahme. Ich habe das vorherige Beispiel erwähnt, bei dem sich Aufrufer täuschen können, wenn sie diesen Parameter an unsere APIs übergeben. Mein Standpunkt hier, entweder sollten wir den Parameter klar benennen, wie ich vorgeschlagen habe (oder einen besseren Namen, wenn Sie einen haben), um die übergebene Zahl anzugeben, die das ISO-Jahr und nicht die gregorianische Jahreszahl angibt. Oder wir müssen die API DateTime übernehmen lassen, was eindeutig anzeigt, dass die API das gregorianische Datum verwendet, und wir können die Grenzfälle gemäß den Monats- und Tageszahlen behandeln, je nachdem, was wir aus dem DateTime-Wert erhalten. Ich verstehe den @khellang- Punkt, dass die Leute die DateTime nicht konstruieren müssen, um nur unsere APIs aufzurufen, und ich stimme ihm zu. Aus diesem Grund habe ich akzeptiert, dass die API die ISO-Jahreszahl übernimmt, und wenn wir in Zukunft feststellen, dass eine Überlastung der API DateTime erfordert, können wir sie hinzufügen.

Ich sehe immer noch, dass es einen Unterschied zwischen dem gregorianischen Jahr und dem ISO-Jahr gibt.

Bitte, es ist ein gregorianisches Jahr und ein ISO-Wochenjahr. ISO-Jahre sind mehrdeutig, entweder "Gregorian" oder "Iso-Woche". Beispielsweise gibt ISO 8601 auch Ordinaldaten an, zB: 2018-117. Das ist ein ISO-Format, und in diesem ISO-Format wäre 2018 eindeutig das ISO-Jahr. Aber es ist nicht dasselbe wie das Jahr der ISO-Woche.

Wenn ich eine DateTime aus einem ISO-Wochendatum konstruiere, ist das Einzige, was Sinn macht, das ISO-Wochenjahr zu verwenden. In diesem Fall ist "iso" im Jahresnamen überflüssig. Damit das sinnvoll ist, müsste es lauten:

public static DateTime ToDateTime(int isoWeekYear, int isoWeekWeek, DayOfWeek isoWeekDay);

Abgesehen davon, dass wir bereits gesagt haben, dass es sich um eine "IsoWeek" -Klasse handelt. das hinzuzufügen ist also albern.

Ich habe Schwierigkeiten, einen Fall zu sehen, in dem ToDateTime ein normales gregorianisches Jahr benötigt, was weiter impliziert, dass "year" bedeutet, dass ISO Week Format Year ausreicht. Wenn ich die anderen 2 Parameter mit dem ISO-Week-System übergebe, wäre es unsinnig, ein traditionelles gregorianisches Jahr mit den anderen Daten aufzunehmen.

Auf jeden Fall macht es mir nichts aus, wenn die Leute der Meinung sind, dass es qualifiziert werden muss, obwohl der Klassenname bereits die IsoWeek-Formatdomäne impliziert. Wenn es jedoch weiter eingeschränkt wird, lehne ich es entschieden ab, den Missbrauch des unsinnigen Begriffs "Iso-Jahr" fortzusetzen. Die meisten der in ISO 8601 spezifizierten Formate haben ein Jahr, das mit dem traditionellen gregorianischen Jahr übereinstimmt. Nur das Jahr des ISO-Wochenformats unterscheidet sich.

@ShawnSteele , was ist dein Vorschlag hier? nennen Sie es einfach "Jahr" und nicht "isoYear"?

@tarekgh - Für DateTimeOffset denke ich, dass dies ein fairer Punkt ist, der berücksichtigt werden sollte. Die Leute könnten am Format ISO 2007-04-05T12:30-02:00 interessiert sein, das eine Zeitzone enthält. Ich würde den Austausch mit UTC nachdrücklich empfehlen, aber Daten/Zeiten sind nicht immer so gut erzogen :(

@ShawnSteele , was ist dein Vorschlag hier? nennen Sie es einfach "Jahr" und nicht "isoYear"?

@tarekgh Ja, nur "Jahr". Die Klasse „IsoWeek“ bietet ausreichend Kontext. Wenn die Leute das Gefühl haben, dass "IsoWeek" immer noch mehrdeutig ist, dann würde ich "IsoWeekFormat" oder etwas Ähnliches vorschlagen, das deutlicher macht, dass es hier nur um das ISO 8601-Wochenformat geht.

Es gibt kein Szenario, in dem es sinnvoll wäre, ein Jahr im Nicht-ISO-Wochenformat zusammen mit einer Woche im ISO-Wochenformat und einem Tag im ISO-Wochenformat zu übergeben.

Für DateTimeOffset denke ich, dass dies ein fairer Punkt ist, der berücksichtigt werden sollte. Die Leute könnten am Format ISO 2007-04-05T12:30-02:00 interessiert sein, das eine Zeitzone enthält. Ich würde den Austausch mit UTC nachdrücklich empfehlen, aber Daten/Zeiten sind nicht immer so gut erzogen :(

Ich glaube nicht. Wir unterstützen derzeit DateTime.ToString("o"), das das ISO-Format gemäß DateTime (und DateTimeOffset) angibt. Ich erwarte kein Iso-Wochenformat einschließlich der Zeitzoneninformationen. unterstützt der Standard ein solches Format?

ok, basierend auf der letzten Diskussion hier der Vorschlag:

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); } }

wäre das für euch alle zumutbar?

Warum enthält die vorgeschlagene API keinen Wochentag?

public static int GetDayOfWeek(DateTime Zeit);

Wenn ich ein Datum im ISO-Wochenformat formatieren möchte, stellt diese Klasse den Jahresteil des ISO-Wochenformats „2018“ und die Wochennummer „17“ bereit, aber es gibt keine Methode, um den Wochentag „7“ zurückzugeben diesen Sonntag.

Eine Analogie wäre wie eine gregorianische Datumsinformationsklasse, die das Jahr, den Monat, aber nicht das Datum (Tag des Monats) liefert.

Ich verstehe völlig, dass dies dem DateTime.DayOfWeek sehr ähnlich ist - der ISO-Wochentag ist jedoch von der Aufzählung versetzt und eine Zahl, keine Aufzählung. Der Code ist "einfach", würde aber immer Munging erfordern, so etwas wie

int isoWeekDay = DateTime.DayOfWeek == 0 ? 7 : (int)DateTime.DayOfWeek;

was einfach ziemlich ungeschickt erscheint, besonders wenn die IsoWeek-Klasse bereits vorhanden ist.

Ich glaube nicht. Wir unterstützen derzeit DateTime.ToString("o"), das das ISO-Format gemäß DateTime (und DateTimeOffset) angibt.

@tarekgh - ja, der Standard unterstützt dieses Format. https://en.wikipedia.org/wiki/ISO_8601#Combined_date_and_time_representations

"Es können entweder einfache oder erweiterte Formate verwendet werden, aber Datum und Uhrzeit müssen dasselbe Format verwenden. Der Datumsausdruck kann Kalender, Woche oder Ordnungszahl sein und muss eine vollständige Darstellung verwenden."

Warum enthält die vorgeschlagene API keinen Wochentag?

Der gregorianische Kalender hat dies bereits. Ich verstehe nicht wirklich, warum wir das tun müssen? Wie ich bereits erwähnt habe, können wir die Bereitstellung von Formatierungsoptionen unabhängig von diesem Vorschlag prüfen. Sie müssen also keine API wie das bereitstellen, was Sie vorschlagen. Die Leute können den Sonntag immer noch in 7 umwandeln, wenn sie dies tun müssen. Wäre übertrieben, eine solche API dafür bereitzustellen.

Ja, der Standard unterstützt dieses Format. https://en.wikipedia.org/wiki/ISO_8601#Combined_date_and_time_representations

Ich interpretiere den Absatz, von dem Sie sprechen, nicht gleich. Es gibt einen Unterschied zwischen der Darstellung des Datums und seiner Formatierung. Ich sehe, dass die ISO-Datumsformatierung immer Jahr und Monat und Tage verwendet (zusätzlich zu Zeit- und Zeitzoneninformationen), aber ich sehe es nirgendwo, wo Sie eine Wochennummer in diesem ISO-Format verwenden können. 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

Sie haben mich verwirrt, indem Sie "das Datum darstellen" und "es formatieren". Alle ISO-Wochendaten sind durch DateTimes darstellbar und benötigen diese Klasse nicht. Die ISO-Wochenformate sind in erster Linie eine Konvention zum Formatieren von gregorianischen Daten in einer Weise, die für einige Unternehmen praktisch ist.

Ich bin es gewohnt, diese Daten in einem Zeitrahmen von „Wochen für ein Projekt“ oder „Tag“ zu sehen, jedoch 2018-W17-05T10:00:00+02:00 (und 2018-117T10:00:00+02: 00) sind von der Norm durchaus erlaubt. Sicher, es könnte im YMD-Format dargestellt werden, aber ISO 8601 erfordert das YMD-Formular nicht für den Datumsteil und ermöglicht Benutzern des Standards zu wählen, wie sie den Datumsteil eines vollständigen Datums- und Uhrzeitformats darstellen möchten. (Benutzer können sich auch dafür entscheiden, UTC oder andere Zeitdarstellungen zu verwenden).

Sicher, viele RFCs und andere Standards spezifizieren das Format 2018-04-27 für Konsistenz und Portabilität, aber ISO 8601 ist nicht so eingeschränkt.

ISO 8601 ist jedoch nicht so eingeschränkt.

Könnten Sie mir bitte den Link vom ISO-Standard schicken, der das zulässt (ich meine, Formate wie 2018-W17-05T10:00:00+02:00 zulassen)? Ich schätze Ihre Hilfe hier.

Außerdem bin ich interessiert, ob Sie ein Codebeispiel schreiben können, wie Sie erwarten, dass die Leute Code schreiben, um unsere vorgeschlagenen APIs mit DateTimeOffset zu verwenden? Ich meine, wann wäre DateTimeOffset vorteilhafter als DateTime? oder mit anderen Worten, wann kümmern sich unsere neuen vorgeschlagenen APIs überhaupt um die Zeit?

Ich glaube nicht, dass DateTimeOffset jetzt angesprochen werden muss. Wir könnten DateTime verwenden und sehen, ob die Leute nach einem DateTimeOffset verlangen. Wenn ja, könnte es später hinzugefügt werden. Ich denke nicht, dass das diese Arbeit blockieren sollte.

Ich bin mit dem Vorschlag einverstanden, den Sie zuletzt gepostet haben.

Danke @ShawnSteele

Ich werde den Vorschlag oben mit Folgendem aktualisieren:

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); } }

Und ich werde den alternativen Designabschnitt entfernen, da das, was wir hier haben, sowieso ein viel besserer Vorschlag ist. Vielen Dank für Ihr wertvolles Feedback.

Für mich ist das perfekt, @tarekgh. Danke!

Sieht gut aus. ISO sollten nicht alle Großbuchstaben sein, aber wir haben bereits Globalisierungs-APIs mit allen Großbuchstaben, so dass das Schiff gesegelt ist.

Das Verschachteln dieses Typs unter dem Kalender zwingt alle dazu, wirklich lange qualifizierte Namen zu verwenden (z. B. Calendar.ISOWeek.GetWeekOfYear() statt nur ISOWeek.GetWeekOfYear() ), daher scheint es besser zu sein, ISOWeek zu einem Typ der obersten Ebene zu machen, insbesondere weil es hilft beim Entdecken.

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 Ich habe dir eine Mitarbeitereinladung geschickt, damit wir dir das Problem zuweisen können (GH-Einschränkung). Ping mich an, sobald du akzeptierst (vorübergehende Zuweisung an mich selbst).
Pro-Tipp: Schalten Sie das Repo auf „Nicht beobachten“, um mehr als 500 Benachrichtigungen täglich zu vermeiden (Sie werden automatisch alle Benachrichtigungen als Mitarbeiter abonniert).

Fertig! Ich beobachte das Repo sowieso seit Jahren 😉

@terrajobst sollte dieses Problem als api-genehmigt markiert werden?

Ja, das wurde genehmigt (Kennzeichnung als solche). Der Computer von @terrajobst war einfach zu langsam, um die Änderung vorzunehmen :(

Nur eine kurze Frage: Sollte dieser Typ zu System.Private.CoreLib (in coreclr) hinzugefügt werden und darauf warten, dass der Code mit corefx und corrt synchronisiert wird? Und dann Typweiterleitung und Tests in System.Globalization hinzufügen?

Nur eine kurze Frage: Sollte dieser Typ zu System.Private.CoreLib (in coreclr) hinzugefügt werden und darauf warten, dass der Code mit corefx und corrt synchronisiert wird? Und dann Typweiterleitung und Tests in System.Globalization hinzufügen?

Ja, bitte fügen Sie den Code zum Coreclr-Repo hinzu und setzen Sie mich bitte auf die PR. Danke.

Vielen Dank!

@tarekgh Ist die Verbesserung in 2.1.1?

Es ist dem 3.0-Meilenstein zugeordnet, also glaube nicht so 🤔

Richtig. 2.1.1 ist Wartung. Wir fügen keine Funktionen oder unkritischen Fixes in Servicing Branches ein, die sie destabilisieren und sie im Grunde zu einem weiteren Master-Branch machen würden.

Danke! Ich sehe einen 3.0-Meilenstein in PRs.

Normalerweise mache ich 1x-2x pro Woche Sweeps von falschen Meilensteinen (wie Zukunft) sowohl für Probleme als auch für PRs.
Ich bin ein bisschen im Verzug wegen einiger High-Pris auf meinem Teller, sorry. Werde nachholen sobald ich kann.

Verstößt ISOWeek nicht gegen die Benennungsrichtlinien des Frameworks?

@paulomorgado Lesen Sie https://github.com/dotnet/corefx/issues/28933#issuecomment -392873426 ein paar Kommentare oben.

Wir fügen keine Funktionen oder unkritischen Fixes in Servicing Branches ein, die sie destabilisieren und sie im Grunde zu einem weiteren Master-Branch machen würden.

@karelz Aber wird das mit 2.2 ausgeliefert?

Entschuldigung @khellang , ich wie auf dem phonw.

Aber wird dies mit 2.2 ausgeliefert?

Traurigerweise Nein. 2.2 ist ein taktisches Release, das vom Release/2.1-Zweig im CoreFX-Repo (2.1-Wartung) abgeschreckt wurde – Hinweis: Das ist eine Repo-spezifische Entscheidung, die sich nicht unbedingt in anderen Repos (ASP.NET, CLI usw.) widerspiegelt. Der Master-Zweig fließt in .NET Core 3.0 im CoreFX-Repository.

Zu spät zur Party: Gab es (nicht finden) eine Diskussion darüber, einen dedizierten Typ (Struct) für eine Wochennummer zu erstellen? - IsoWeek / IsoWeekNumber / WeekNumber mit den Eigenschaften Year und Week .
IMHO scheint es prägnanter zu sein, als zwei Methoden aufrufen zu müssen, um zwei Zahlen zu erhalten, die eine einzige Sache darstellen.
Ich bin mir nicht sicher, wie andere Leute Wochennummern verwenden, aber ich brauchte in den meisten Fällen sowohl die Woche als auch das Jahr zusammen.

Gab es eine Diskussion darüber, einen speziellen Typ für eine Wochennummer zu erstellen?

NÖ. Bei dem Vorschlag ging es immer um Methoden, um die Informationen zu erhalten, die Sie in verschiedenen Situationen benötigen. Das Erstellen eines Typs, der diese Zahlen umschließt, wäre ein anderer Vorschlag.

IMHO scheint es prägnanter zu sein, als zwei Methoden aufrufen zu müssen, um zwei Zahlen zu erhalten, die eine einzige Sache darstellen.

Welche Anrufe meinen Sie? Welche Informationen haben Sie und welche Informationen interessieren Sie?

Wenn Sie "ein einzelnes Ding" haben, das aus zwei Zahlen besteht, ist es sehr sinnvoll, diese Methoden aufzuteilen. Das Schreiben einer Wrapping-Struktur und das Zusammenstellen dieser Methoden zu einem späteren Zeitpunkt ist trivial.

Auch etwas spät zur Party, aber warum ist der Rückgabewert eins int ? Wisse, dass 2016-01-02 in die Woche 2015.53 fiel und 2019-12-31 in die Woche 2020.01 wird

Ich kann so etwas immer noch nicht verwenden:
```c#
int week = ISOWeek.GetWeekOfYear(new 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++;

Warum nicht ein Tupel zurückgeben?
c# public static (int year, int week) GetWeekOfYear(DateTime date);

Warum nicht ein Tupel zurückgeben?

@ffes Wenn Sie var d = new DateTime(2016, 1, 2) haben, sollten Sie dazu in der Lage sein

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

Wenn Sie das in eine einzige Methode packen möchten, die ein Tupel zurückgibt, sollte das ziemlich einfach sein.

Ich habe die Existenz von GetYear() übersehen. Sorry für den Lärm :erleichtert: