Rrule: Не выводить DTSTART в toString()

Созданный на 25 янв. 2015  ·  11Комментарии  ·  Источник: jakubroztocil/rrule

DTSTART и DTEND не являются частью iCalendar RRULE и не должны включаться при выполнении .toString().

Возможно, сгенерируйте что-то вроде «DTSTART=x;DTEND=x;RRULE=x», что будет допустимым синтаксисом iCalendar.

enhancement

Самый полезный комментарий

:+1: по этому вопросу

AFAIK, DTSTART всегда должен быть другой строкой, а не просто разделенной ; , как в примере, указанном в # 84 (новые строки имеют значение):

DTSTART;TZID=US-Eastern:19970902T090000
RRULE:FREQ=WEEKLY;INTERVAL=2;UNTIL=19971224T000000Z;WKST=SU;BYDAY=MO,WE,FR

Я не _думаю_ (но жду исправления, если ошибаюсь), что объединение этих строк с ; допустимо в соответствии с RFC 5545.

Все 11 Комментарий

также плюс 1 это

Согласен - это вызывает некоторые проблемы при взаимодействии с другими реализациями (например, _Python dateutil_)

:+1: по этому вопросу

AFAIK, DTSTART всегда должен быть другой строкой, а не просто разделенной ; , как в примере, указанном в # 84 (новые строки имеют значение):

DTSTART;TZID=US-Eastern:19970902T090000
RRULE:FREQ=WEEKLY;INTERVAL=2;UNTIL=19971224T000000Z;WKST=SU;BYDAY=MO,WE,FR

Я не _думаю_ (но жду исправления, если ошибаюсь), что объединение этих строк с ; допустимо в соответствии с RFC 5545.

@jkbrzt вы принимаете запросы на извлечение для этого?

Поскольку это было бы критическим изменением, я мог бы представить его реализацию в отдельной функции, например, icalString() , а также дать возможность синтаксическому анализатору.

Для всех, кто сталкивается с этой проблемой, я создал вспомогательную функцию, которая, кажется, работает для моих нужд (примечание: она написана на машинописном языке)

export function rrulesetToIcalString(schedule: RRuleSet, startDate: Moment): string {
  // matches `;DTSTART=20180125T080000Z` until `;` or end
  const icalStrings = schedule.valueOf().map(ruleString => ruleString.replace(/;DTSTART=.*?(?=(?:;)|$)/, ''));

  icalStrings.unshift(`DTSTART;TZID=UTC:${startDate.utc().format('YYYYMMDDTHHmmss')}`);

  return icalStrings.join('\n');
}

Вы даете ему RRuleSet и startDate (я настроил его для использования с датами Moment , но вы поняли идею), и он проходит и удаляет все разделы ;DTSTART=...; в набор RRuleSet. Затем он добавляет один правильно отформатированный раздел DTSTART в начале набора правил, а затем объединяет все разделы вместе.

Примечание. Я _думаю_, что присутствует только одно значение DTSTART . Однако, возможно, есть варианты iCalendar, где это не так (за пределами моего варианта использования).

Чтобы получить совместимую строку правила (без DTSTART), одним из вариантов является прямое использование RRule.optionsToString :

var rule = new RRule({
   freq: RRule.WEEKLY,
   interval: 5,
   byweekday: [RRule.MO, RRule.FR],
   dtstart: new Date(2012, 1, 1, 10, 30),
   until: new Date(2012, 12, 31)
});
var copy = Object.assign({}, rule.origOptions);
delete copy.dtstart
RRule.optionsToString(copy)

Есть новости по этому поводу? Не так сложно получить совместимую строку rrule, благодаря совету @phillbaker , но было бы неплохо иметь возможность подключить и играть с Python dateutil.

Согласитесь, есть некоторые различия в синтаксисе RFC и Python. Был бы очень открыт для запроса на вытягивание, касающегося этого!

Теперь, когда был реализован TZID (#261), библиотека больше не может анализировать строки, которые она выводит. Я думаю, что обратно совместимое решение может быть достигнуто путем продолжения анализа выходных строк до 2.4.0, но вывода строк, совместимых с RFC.

^ мое последнее утверждение здесь («библиотека больше не может анализировать строки, которые она выводит») теперь неверно, это было только что исправлено # 267. Тем не менее, было бы идеально соответствовать RFC!

Исправлено #269

Была ли эта страница полезной?
0 / 5 - 0 рейтинги

Смежные вопросы

kirrg001 picture kirrg001  ·  5Комментарии

grigio picture grigio  ·  7Комментарии

michaelkrog picture michaelkrog  ·  9Комментарии

jimmywarting picture jimmywarting  ·  9Комментарии

marcoancona picture marcoancona  ·  22Комментарии