Open DarryQueen opened 2 years ago
@davidgoli bump.
I hate to bump threads, but this is a really simple one-line change that fixes a quite annoying bug. See also the discussion here: #486. @jakubroztocil, is there something blocking this?
@jakubroztocil hello! Could you please merge this or is something blocking it? Im having compatibility issues with php-rrule and rrulejs
See also #596
The spec isn't quite that simple:
The value of the UNTIL rule part MUST have the same value type as the "DTSTART" property. Furthermore, if the "DTSTART" property is specified as a date with local time, then the UNTIL rule part MUST also be specified as a date with local time. If the "DTSTART" property is specified as a date with UTC time or a date with local time and time zone reference, then the UNTIL rule part MUST be specified as a date with UTC time.
So if DTSTART is a local time without time zone, then UNTIL must also be in local time, but if DTSTART is either UTC or has a time zone reference then UNTIL is in UTC. (This doesn't seem like correct behavior to me, but I didn't write the spec.)
Any updates on the topic? This causes a mismatch for me while parsing rrule output on the backend, for now, as a workaround I just sneak in a Z at the end of the until definition via a regex, which doesn't seem like the most bulletproof solution :D
In the current behavior, the
until
date string is in UTC iff theTZID
is not specified. According to the RRule spec:By this spec, the
until
date string should be in UTC if the converse is true - i.e.TZID
is specified. So we should always use UTC foruntil
.Note that python-dateutil library actually throws an error if
TZID
is specified fordtstart
anduntil
is not in UTC according to StackOverflow.