Rrule: Debería usar DTSTART como primera aparición

Creado en 25 ene. 2015  ·  10Comentarios  ·  Fuente: jakubroztocil/rrule

Según la especificación de iCalendar:

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

E incluye un ejemplo de esto:

 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 no incluye el 2 de septiembre como ocurrencia. En rrule.js, la primera aparición es el 3 de septiembre.

Comentario más útil

Estoy de acuerdo, por defecto el dtstart debería ser inclusivo para ser más consistente con otros sistemas.

Hice un codepen demostrando las sutilezas del comportamiento actual: https://codepen.io/arshaw/pen/qwEQNO?editors=0010

Todos 10 comentarios

Más 1 en esto. RRule no respeta la fecha de inicio / duración en la aplicación de demostración en absoluto

De acuerdo, esto me desconcertó al tratar con Google RFC 2445 java lib.

: +1: Así es como funcionan los sistemas estándar (y compatibles como Google Calendar, Apple (Mac OS / iOS / iCloud) Calendar.

@jkbrzt , en este momento, rrule.js está vinculado a la funcionalidad de python dateutil

A diferencia de lo documentado en el RFC, la fecha y hora de inicio (dtstart) no es la primera instancia de repetición, a menos que se ajuste a las reglas especificadas.
–– dateutil docs

Esto parecería una gran desviación de dateutil, que parecería tener sentido en este caso. Implicaría cambiar casi todos los casos de prueba. ¿Pensamientos? ¿Apoyarías el cambio?

@hwangmoretime He combinado sus cambios en el archivo README para documentar dónde rrule.js difiere del RFC, gracias por eso. Sí, tendría mucho sentido hacer compatible con rrule.js (este problema + el argumento de palabra clave byday ). Sin embargo, romperá la compatibilidad con versiones anteriores, por lo que debe estar bien documentado.

Creo que esto todavía tiene un error. Esto funciona para all() pero no para el método between . En el siguiente ejemplo, configuro dtstart y rdate en un objeto RRuleSet , según el archivo Léame.

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

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

tenga en cuenta que para la llamada al método all , la fecha devuelta coincide con el dtstart pero para between , vuelve a la hora actual por defecto

aquí hay un poco más de contexto. Por lo que puedo decir, el rruleset está haciendo exactamente lo contrario de lo que esperaba. Produce una lista de fechas, donde el elemento cero es el inicio del evento deseado original. Pero es la hora actual que se expande en una serie de fechas. Esperaba obtener una lista de fechas el 21 de enero, pero rruleset "recurrió" usando la hora actual (22 de marzo).

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

He retirado el repositorio y estoy tratando de reducir esto con algunas pruebas, pero se agradece cualquier consejo.

Tuve un problema similar con dtstart. Consulte https://stackoverflow.com/questions/54517101/rrule-not-setting-correct-time-if-dtstart-is-set
Cuando configuro dtstart en el constructor, obtengo las horas correctas con .all () pero si configuro dtstart después, obtengo la hora actual.

Estoy de acuerdo, por defecto el dtstart debería ser inclusivo para ser más consistente con otros sistemas.

Hice un codepen demostrando las sutilezas del comportamiento actual: https://codepen.io/arshaw/pen/qwEQNO?editors=0010

por defecto, dtstart debería ser inclusivo para ser más consistente con otros sistemas.

Acordado. Ponerse al día sobre rrule ahora. Es un gran ahorro de tiempo (¡gracias!), Pero esta fecha inclusiva emite un matiz extraño que requiere una lógica personalizada para abordar. Me encantaría ver esto actualizado. Entendí que el comportamiento actual es consistente con python-dateutil, pero creo que la prioridad debería ser el comportamiento consistente con el estándar RFC, en lugar de perpetuar una desviación extraña.

Además, por comentario a continuación:

Tenga en cuenta que puede obtener el comportamiento original utilizando un RRuleSet y agregando dtstart como rdate.

Lo mejor que puedo decir es que esto subestima significativamente la complejidad de la solución alternativa necesaria para muchos casos de uso.

Por ejemplo, suponga que tiene los siguientes parámetros de reglas:

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

Esto debería traducirse como "cada 2 semanas el lunes 10 veces", con una fecha de inicio el domingo 1 de noviembre de 2020.

Ahora, el primer lunes calendario después de la fecha de inicio es el 2 de noviembre ... así que, con un intervalo de 2, esperaríamos que las fechas de los eventos generados sean el 2 de noviembre, el 16 de noviembre, el 30 de noviembre, etc.

Sin embargo, el paquete rrule cambio nos da fechas del 9 de noviembre, 23 de noviembre, etc. En otras palabras, todo nuestro intervalo es incorrecto, desplazado una semana hacia adelante. Arreglar esto no es tan simple como "usar un RRuleSet y agregar el dtstart como un rdate". Hay bastante más trabajo para este tipo de corrección.

image

¿Fue útil esta página
0 / 5 - 0 calificaciones

Temas relacionados

shorlbeck picture shorlbeck  ·  21Comentarios

marcoancona picture marcoancona  ·  22Comentarios

elazar picture elazar  ·  18Comentarios

maconfr picture maconfr  ·  6Comentarios

Prinzhorn picture Prinzhorn  ·  15Comentarios