Day repeats when day light savings time starts about rrule HOT 5 CLOSED

Similar: #32
Related: #38

from rrule.

I am just going to bring up a workaround here as it looks this may be a more complex issue. You can work in the UTC timezone and convert your result back to NZST. Using Moment.js that would be:

new RRule({
    freq: RRule.DAILY,
    dtstart: moment(new Date(2014, 8, 26, 10, 30)).tz("UTC").toDate(),
    count: 4
}).all()
    .map(function (dt) {
        return moment(dt).tz("NZST").toDate()
    })
    .map(function (dt) {
        return dt.toISOString()
    });

[
    "2014-09-25T22:30:00.000Z",
    "2014-09-26T22:30:00.000Z",
    "2014-09-27T21:30:00.000Z",
    "2014-09-28T21:30:00.000Z"
]

from rrule.

Thanks for the workaround suggestion, @lyschoening. Unfortunately, it has no effect becase moment(new Date(2014, 8, 26, 10, 30)).tz("UTC").toDate() is identical to new Date(2014, 8, 26, 10, 30).

I've isolated the problem to dateutil.fromOrdinal(). This function adjusts the resulting date by adding the offset. However, when crossing a DST boundary the offset becomes incorrect. For example:

For ordinal day 16341 (2014-09-28), the correct result should be Sun Sep 28 2014 00:00:00 GMT+1200 (NZST). However, new Date(millisecsFromBase + dateutil.tzOffset(new Date(millisecsFromBase))) returns Sun Sep 28 2014 13:00:00 GMT+1300 (NZDT) which is after DST kicks in at 02:00. The offset, 13 hours, is then applied but, because it crosses the DST boundary, it actually returns Sat Sep 27 2014 23:00:00 GMT+1200 (NZST) which, although technically correct, is effectively the wrong date for the purposes of this function.

I'm writing a patch for fromOrdinal() which will take into account the difference in offsets when crossing a DST boundary. I'll generate a pull request when I've done a bit of testing.

from rrule.

As a side note, and please correct me if I'm wrong, but it looks like part of the equation in dateutil.fromOrdinal() is redundant:

...dateutil.ORDINAL_BASE.getTime() - dateutil.tzOffset(dateutil.ORDINAL_BASE)...

This will always return zero so there's no need to calculate it.

from rrule.

I believe this may be fixed. Please reopen if you are still experiencing issues.

from rrule.