TZID is ignored when converting rrule to string

[egeersoz]

I have the following:

let eventRrule = new RRule({
    freq: 3,
    dtstart: moment("2019-09-18T08:00:00-05:00").toDate(),
    tzid: "America/Chicago"
})

This results in:

So far so good.

However, when I run eventRrule.toString(), I get the following:

DTSTART;TZID=America/Chicago:20190918T130000↵RRULE:FREQ=DAILY

This seems wrong - it actually is wrong, as it results in the calendar rendering the events at 1pm every day, when they are in fact at 8 am. My timezone is America/Chicago, and the tzid specified in the rule is also America/Chicago. I cannot conceive of a reason why converting the rule to string would turn DTSTART into a UTC date, while keeping tzid the same.

My app uses "wall time" for everything, and this library's assumption that everything is UTC or must be UTC is throwing a serious curveball into everything. UTC is actually not the right way to deal with events that happen in the future.

In the short term, I'm looking for a way to make toString() generate a string representation of the dtstart property of the rrule as is. Is that possible?

[jorroll]

I cannot conceive of a reason why converting the rule to string would turn DTSTART into a UTC date, while keeping tzid the same.

You don't have to conceive of a reason, you can simply read the docs and find out the reason: https://github.com/jakubroztocil/rrule#important-use-utc-dates.

You're running into this problem because you're passing a non-utc date to dtstart.

You may find it easier to instantiate an rrule from a string

let eventRrule = RRule.fromString(
  "DTSTART;TZID=America/Chicago:20190918T080000\nRRULE:FREQ=DAILY"
)

[egeersoz]

I read the docs, but it seems you didn't read what I wrote fully:

"I cannot conceive of a reason why converting the rule to string would turn DTSTART into a UTC date, while keeping tzid the same."

Converting this to a string:

dtstart: Wed Sep 18 2019 08:00:00 GMT-0500 (Central Daylight Time)

Needs to yield DTSTART;TZID=Etc/UTC:20190918T130000, not DTSTART;TZID=America/Chicago:20190918T130000.

[jorroll]

I can't tell if you understand how rrulejs works, and you're just upset about it, or if you don't understand the API.

Javascript dates don't have a flag to indicate if they are in the UTC vs local timezones. You seem to think that you gave this date to the RRule as the start time moment("2019-09-18T08:00:00-05:00").toDate().toString(). You didn't. You gave this as the start time moment("2019-09-18T08:00:00-05:00").toDate().toUTCString() (and again, rrulejs treats that UTC value as the local time).

[egeersoz]

I think I understand how rrulejs works. The timezone support part is the part that is confusing, and lots of people on this issue board have voiced confusion and criticism of how this library implements it. You are correct that I am frustrated, as I've spent the last three days trying to get it to work properly.

In any case, if you don't think this is a bug, we can go ahead and close this issue. I'll continue fiddling with it.

[jorroll]

Well I'm not a maintainer of this library, but I'm pretty confident in saying that this behavior is not a bug. It is annoying, but this is a volunteer project and this implementation made life easier on the original volunteers. There are other recurrence libraries you could try if you're dissatisfied with this one (e.g. rSchedule, dayspan). However, rrulejs is the only javascript recurrence library that I'm aware of with support for every ICAL recurrence rule.

[egeersoz]

Yeah I saw that you work on rSchedule. I have a lot of respect for open-source maintainers. Apologies for my earlier tone, I didn't mean to come across as a jerk. Thank you for your help and have a wonderful day!

[stupidtools]

Spent a day trying to get this to work, then decided to just leave the times all in UTC and handle DST offsets in the app level code.