Rrule: Harus menggunakan DTSTART sebagai kemunculan pertama

Dibuat pada 25 Jan 2015 · 10Komentar · Sumber: jakubroztocil/rrule

Menurut spesifikasi iCalendar:

 The "DTSTART" property defines the first instance in the recurrence set.

Dan itu termasuk contohnya:

 Every other week on Monday, Wednesday and Friday until December 24,
 1997, but starting on Tuesday, September 2, 1997:

 DTSTART;TZID=US-Eastern:19970902T090000
 RRULE:FREQ=WEEKLY;INTERVAL=2;UNTIL=19971224T000000Z;WKST=SU;
  BYDAY=MO,WE,FR
 ==> (1997 9:00 AM EDT)September 2,3,5,15,17,19,29;October
 1,3,13,15,17
     (1997 9:00 AM EST)October 27,29,31;November 10,12,14,24,26,28;
                       December 8,10,12,22

rrule.js tidak memasukkan 2 September sebagai kejadian. Di rrule.js kejadian pertama adalah 3 September.

Sumber

espen

👍7

Komentar yang paling membantu

Saya setuju, secara default dtstart harus inklusif agar lebih konsisten dengan sistem lain.

Saya membuat codepen yang menunjukkan seluk-beluk perilaku saat ini: https://codepen.io/arshaw/pen/qwEQNO?editors=0010

arshaw pada 2 Apr 2019

👍2

Semua 10 komentar

Ditambah 1 ini. RRule sama sekali tidak menghormati tanggal mulai/durasi di aplikasi demo

GeoffreyEmery pada 19 Feb 2015

😕3

Setuju, ini membuat saya kecewa ketika berhadapan dengan Google RFC 2445 Java lib.

bsaverino pada 13 Mei 2015

:+1: Beginilah cara kerja standar (dan sistem yang sesuai seperti Google Kalender, Apple (Mac OS/iOS/iCloud).

tilthouse pada 19 Nov 2015

@jkbrzt , Saat ini, rrule.js terkait dengan fungsionalitas python dateutil

Tidak seperti yang didokumentasikan dalam RFC, waktu mulai (dtstart) bukanlah contoh perulangan pertama, kecuali jika sesuai dengan aturan yang ditentukan.
–– dokumen dateutil

Ini akan tampak seperti penyimpangan besar dari dateutil, yang tampaknya masuk akal dalam kasus ini. Ini akan melibatkan perubahan hampir semua kasus uji. Pikiran? Apakah Anda akan mendukung perubahan itu?

hwangmoretime pada 22 Feb 2016

👍2

@hwangmoretime Saya telah menggabungkan perubahan Anda ke dokumentasi README di mana rrule.js berbeda dari RFC, terima kasih untuk itu. Ya, sangat masuk akal untuk membuat rrule.js sesuai (masalah ini + argumen kata kunci byday ). Ini akan merusak kompatibilitas ke belakang sehingga perlu didokumentasikan dengan baik.

jakubroztocil pada 24 Feb 2016

Saya percaya ini masih memiliki bug. Ini berfungsi untuk all() tetapi tidak untuk metode between . Pada contoh di bawah ini, saya menetapkan dtstart dan rdate pada objek RRuleSet , sesuai dengan readme.

screen shot 2016-03-19 at 1 41 49 pm

aturanSet
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)]

perhatikan bahwa untuk panggilan ke metode all , tanggal yang dikembalikan cocok dengan dtstart tetapi untuk between , defaultnya kembali ke waktu saat ini

adamwong246 pada 19 Mar 2016

di sini sedikit lebih banyak konteks. Sejauh yang saya tahu, rruleset melakukan kebalikan dari apa yang saya harapkan. Ini menghasilkan daftar tanggal, di mana elemen nol adalah awal dari acara yang diinginkan asli. Tapi ini adalah waktu saat ini diperluas menjadi serangkaian tanggal. Saya berharap mendapatkan daftar tanggal pada 21 Januari, tetapi rruleset "berulang" menggunakan waktu saat ini (22 Maret).

screen shot 2016-03-22 at 6 02 21 pm

Saya telah menarik repo dan mencoba mempersempitnya dengan beberapa tes tetapi saran apa pun dihargai.

adamwong246 pada 23 Mar 2016

Saya memiliki masalah serupa dengan dtstart. Lihat https://stackoverflow.com/questions/54517101/rrule-not-setting-correct-time-if-dtstart-is-set
Ketika saya mengatur dtstart di konstruktor, saya mendapatkan waktu yang benar dengan .all() tetapi jika saya mengatur dtstart setelahnya, saya mendapatkan waktu saat ini.

danydhondt pada 4 Feb 2019

Saya setuju, secara default dtstart harus inklusif agar lebih konsisten dengan sistem lain.

Saya membuat codepen yang menunjukkan seluk-beluk perilaku saat ini: https://codepen.io/arshaw/pen/qwEQNO?editors=0010

arshaw pada 2 Apr 2019

👍2

secara default dtstart harus inklusif agar lebih konsisten dengan sistem lain.

Sepakat. Dapatkan kecepatan di rrule sekarang. Ini adalah penghemat waktu yang hebat (terima kasih!), tetapi tanggal inklusif ini mengeluarkan nuansa aneh yang memerlukan beberapa logika khusus untuk ditangani. Akan senang melihat ini diperbarui. Dipahami bahwa perilaku saat ini konsisten dengan python-dateutil, tapi saya pikir prioritas harus pada perilaku yang konsisten dengan standar RFC, daripada melanggengkan penyimpangan aneh.

Juga, per komentar di bawah ini:

Perhatikan bahwa Anda bisa mendapatkan perilaku asli dengan menggunakan RRuleSet dan menambahkan dtstart sebagai rdate.

Sejauh yang saya tahu, ini secara signifikan mengecilkan kompleksitas solusi yang diperlukan untuk banyak kasus penggunaan.

Misalnya, anggap Anda memiliki parameter aturan berikut:

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

Ini harus diterjemahkan menjadi "setiap 2 minggu pada hari Senin selama 10 kali", dengan tanggal mulai pada hari Minggu, 1 November 2020.

Sekarang, kalender pertama Senin setelah tanggal mulai adalah 2 November... jadi, dengan interval 2, kami berharap tanggal acara yang dihasilkan adalah 2 November, 16 November, 30 November, dll.

Namun, paket rrule malah memberi kami tanggal 9 Nov, 23 Nov, dll. Dengan kata lain, seluruh interval kami salah, bergeser satu minggu ke depan. Memperbaiki ini tidak sesederhana "menggunakan RRuleSet dan menambahkan dtstart sebagai rdate." Ada sedikit lebih banyak pekerjaan untuk jenis perbaikan ini.