Rrule: Sollte DTSTART als erstes Vorkommen verwenden

Plus 1 dazu. RRule berücksichtigt das Startdatum/die Dauer der Demo-App überhaupt nicht

Zugegeben, das hat mich beim Umgang mit Google RFC 2445 java lib abgeschreckt.

:+1: So funktioniert der Standard (und kompatible Systeme wie Google Kalender, Apple (Mac OS/iOS/iCloud) Kalender).

@jkbrzt , Im Moment ist rrule.js an die Funktionalität von Python dateutil gebunden

Anders als im RFC dokumentiert, ist das Startdatum (dtstart) nicht die erste Wiederholungsinstanz, es sei denn, es passt in die angegebenen Regeln.
–– dateutil-Dokumente

Dies scheint eine große Abweichung von dateutil zu sein, was in diesem Fall sinnvoll erscheint. Es würde bedeuten, fast alle Testfälle zu ändern. Die Gedanken? Würden Sie die Änderung unterstützen?

@hwangmoretime Ich habe Ihre Änderungen an der README-Dokumentation zusammengeführt, in der sich rrule.js vom RFC unterscheidet, danke dafür. Ja, es wäre sehr sinnvoll, rrule.js konform zu machen (dieses Problem + das byday Schlüsselwortargument). Es wird jedoch die Abwärtskompatibilität beeinträchtigen, daher muss es gut dokumentiert werden.

Ich glaube, das hat noch einen Bug. Dies funktioniert für all() aber nicht für die Methode between . Im folgenden Beispiel setze ich dtstart und rdate für ein RRuleSet Objekt, wie in der Readme-Datei angegeben.

RegelSet
RRuleSet {_cache: Object, _rrule: Array[1], _rdate: Array[1], _exrule: Array[0], _exdate: Array[0]}

rruleSet.valueOf()
["RRULE:FREQ=YEARLY;DTSTART=20120122T000000Z;INTERVAL=1;WKST=0;BYMONTH=3;BYMONTHDAY=19;BYHOUR=13;BYMINUTE=39;BYSECOND=27", "RDATE:20120122T000000Z"]

rruleSet.all()[0]
Sat Jan 21 2012 16:00:00 GMT-0800 (PST)

rruleSet.between(startDatetime, endDatetime)
[Sat Mar 19 2016 13:39:27 GMT-0700 (PDT)]

Beachten Sie, dass für den Aufruf der Methode all das zurückgegebene Datum mit dem ursprünglichen dtstart übereinstimmt, aber für between standardmäßig auf die aktuelle Zeit zurückgesetzt wird

hier ist ein bisschen mehr Kontext. Soweit ich das beurteilen kann, macht das Regelset genau das Gegenteil von dem, was ich erwartet habe. Es erzeugt eine Liste von Datumsangaben, wobei das nullte Element der Beginn des ursprünglichen gewünschten Ereignisses ist. Aber es ist die aktuelle Zeit, die in eine Reihe von Daten erweitert wird. Ich hatte erwartet, am 21. Januar eine Liste mit Daten zu erhalten, aber das Regelwerk "wiederkehrt" mit der aktuellen Zeit (22. März).

Ich habe das Repo gezogen und versuche, dies mit einigen Tests einzugrenzen, aber jeder Rat ist willkommen.

Ich hatte ein ähnliches Problem mit dtstart. Siehe https://stackoverflow.com/questions/54517101/rrule-not-setting-correct-time-if-dtstart-is-set
Wenn ich dtstart im Konstruktor setze, bekomme ich mit .all() korrekte Zeiten, aber wenn ich dtstart danach setze, bekomme ich die aktuelle Uhrzeit.

Ich stimme zu, dass dtstart standardmäßig inklusive sein sollte, um konsistenter mit anderen Systemen zu sein.

Ich habe einen Codepen erstellt, der die Feinheiten des aktuellen Verhaltens demonstriert: https://codepen.io/arshaw/pen/qwEQNO?editors=0010

standardmäßig sollte dtstart inklusive sein, um konsistenter mit anderen Systemen zu sein.

Einverstanden. Machen Sie sich jetzt mit der Regel vertraut. Es ist eine großartige Zeitersparnis (danke!), aber dieses inklusive Datumsproblem ist eine seltsame Nuance, die eine benutzerdefinierte Logik erfordert. Würde das gerne aktualisiert sehen. Ich habe das aktuelle Verhalten im Einklang mit python-dateutil verstanden, aber ich denke, dass das Verhalten im Einklang mit dem RFC-Standard Priorität haben sollte, anstatt eine seltsame Abweichung zu verewigen.

Außerdem pro Kommentar unten:

Beachten Sie, dass Sie das ursprüngliche Verhalten erhalten können, indem Sie ein RRuleSet verwenden und dtstart als rdate hinzufügen.

Soweit ich das beurteilen kann, wird die Komplexität der für viele Anwendungsfälle erforderlichen Problemumgehung deutlich unterschätzt.

Angenommen, Sie haben die folgenden Regelparameter:

new RRule({
  freq: RRule.WEEKLY,
  dtstart: new Date(Date.UTC(2020, 10, 1, 21, 0, 0)),
  count: 10,
  interval: 2,
  byweekday: RRule.MO
})

Dies sollte sich in "alle 2 Wochen am Montag für 10 Mal" mit einem Startdatum am Sonntag, dem 1. November 2020, übersetzen.

Nun, der allererste Kalendermontag nach dem Startdatum ist der 2. November. Bei einem Intervall von 2 würden wir also erwarten, dass die generierten Ereignisdaten der 2. November, 16. November, 30. November usw. sind.

Das Paket rrule gibt uns jedoch stattdessen Daten vom 9. November, 23. November usw. Mit anderen Worten, unser gesamtes Intervall ist falsch, eine Woche nach vorne verschoben. Dies zu beheben ist nicht so einfach wie "Verwenden eines RRuleSet und Hinzufügen von dtstart als rdate". Es gibt einiges mehr Arbeit für diese Art von Fix.