Rrule: Deve usar DTSTART como primeira ocorrência

Criado em 25 jan. 2015 · 10Comentários · Fonte: jakubroztocil/rrule

De acordo com a especificação do iCalendar:

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

E inclui um exemplo disso:

 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 não inclui 2 de setembro como uma ocorrência. Em rrule.js, a primeira ocorrência é 3 de setembro.

Fonte

espen

👍7

Comentários muito úteis

Eu concordo, por padrão, dtstart deve ser inclusivo para ser mais consistente com outros sistemas.

Fiz um codepen demonstrando as sutilezas do comportamento atual: https://codepen.io/arshaw/pen/qwEQNO?editors=0010

arshaw em 2 abr. 2019

👍2

Todos 10 comentários

Mais 1 nisso. O RRule não está honrando a data de início / duração no aplicativo de demonstração

GeoffreyEmery em 19 fev. 2015

😕3

Concordo, isso me confundiu ao lidar com o java lib RFC 2445 do Google.

bsaverino em 13 mai. 2015

: +1: É assim que funciona o calendário padrão (e sistemas compatíveis, como Google Calendar, Apple (Mac OS / iOS / iCloud).

tilthouse em 19 nov. 2015

@jkbrzt , No momento, rrule.js está vinculado à funcionalidade do python dateutil

Ao contrário do documentado na RFC, a data e hora de início (dtstart) não é a primeira instância de recorrência, a menos que se encaixe nas regras especificadas.
–– dateutil docs

Isso pareceria um grande afastamento do dateutil, o que faria sentido neste caso. Isso envolveria a mudança de quase todos os casos de teste. Pensamentos? Você apoiaria a mudança?

hwangmoretime em 22 fev. 2016

👍2

@hwangmoretime Eu rrule.js compatível (este problema + o argumento de palavra-chave byday ). No entanto, ele quebrará a compatibilidade com versões anteriores, por isso precisa ser bem documentado.

jakubroztocil em 24 fev. 2016

Eu acredito que isso ainda tem um bug. Isso funciona para all() mas não para o método between . No exemplo abaixo, eu defino dtstart e rdate em um objeto RRuleSet , conforme o readme.

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

note que para a chamada ao método all , a data retornada corresponde ao dtstart mas para between , o padrão é a hora atual

adamwong246 em 19 mar. 2016

aqui está um pouco mais de contexto. Pelo que eu posso dizer, o conjunto de regras está fazendo exatamente o oposto do que eu esperava. Ele produz uma lista de datas, onde o elemento zero é o início do evento original desejado. Mas é a hora atual que é expandida para uma série de datas. Esperava obter uma lista de datas em 21 de janeiro, mas o rruleset "voltou" usando a hora atual (22 de março).

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

Retirei o repositório e estou tentando restringir isso com alguns testes, mas agradecemos qualquer conselho.

adamwong246 em 23 mar. 2016

Tive um problema semelhante com o dtstart. Consulte https://stackoverflow.com/questions/54517101/rrule-not-setting-correct-time-if-dtstart-is-set
Quando defino dtstart no construtor, obtenho a hora correta com .all (), mas se defino dtstart posteriormente, obtenho a hora atual.

danydhondt em 4 fev. 2019

Eu concordo, por padrão, dtstart deve ser inclusivo para ser mais consistente com outros sistemas.

Fiz um codepen demonstrando as sutilezas do comportamento atual: https://codepen.io/arshaw/pen/qwEQNO?editors=0010

arshaw em 2 abr. 2019

👍2

por padrão, dtstart deve ser inclusivo para ser mais consistente com outros sistemas.

Concordou. Aprimorando a regra agora. É uma grande economia de tempo (obrigado!), Mas essa data inclusiva apresenta uma nuance estranha que requer alguma lógica personalizada para ser resolvida. Adoraria ver isso atualizado. Compreendi esse comportamento atual consistente com python-dateutil, mas acho que a prioridade deve ser no comportamento consistente com o padrão RFC, em vez de perpetuar um desvio ímpar.

Além disso, por comentário abaixo:

Observe que você pode obter o comportamento original usando um RRuleSet e adicionando o dtstart como um rdate.

Pelo que posso dizer, isso atenua significativamente a complexidade da solução alternativa necessária para muitos casos de uso.

Por exemplo, suponha que você tenha os seguintes parâmetros de regra:

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

Isso deve ser traduzido como "a cada 2 semanas na segunda-feira, 10 vezes", com data de início no domingo, 1º de novembro de 2020.

Agora, a primeira segunda-feira após a data de início é 2 de novembro ... então, com um intervalo de 2, esperaríamos que as datas dos eventos gerados fossem 2 de novembro, 16 de novembro, 30 de novembro, etc.

No entanto, o pacote rrule nos dá datas de 9 de novembro, 23 de novembro, etc. Em outras palavras, todo o nosso intervalo está errado, deslocado uma semana para a frente. Consertar isso não é tão simples quanto "usar um RRuleSet e adicionar o dtstart como um rdate." Há um pouco mais de trabalho para esse tipo de correção.