Catches the TZInfo::PeriodNotFound exception and retries the cron for on...

[snicker]

...e hour in the future and also changes the periodic cleanup to 11:59PM

This needs some refactoring, but a ruby wizard I am not. maybe move that block into it's own method?

[snicker]

fix for #180

[cantino]

Interesting, so shifting it an hour fixes it for you?

[snicker]

Yup, that was the recommendation. TZInfo throws two diff exceptions,
there's probably another that needs to be monitored for "falling back"

On Mar 8, 2014, at 18:06, Andrew Cantino notifications@github.com wrote:

Interesting, so shifting it an hour fixes it for you?

[cantino]

But do we need to restore to the normal schedule in a day or two?

On Saturday, March 8, 2014, snicker notifications@github.com wrote:

Yup, that was the recommendation. TZInfo throws two diff exceptions,
there's probably another that needs to be monitored for "falling back"

On Mar 8, 2014, at 18:06, Andrew Cantino <notifications@github.comjavascript:_e(%7B%7D,'cvml','notifications@github.com');>
wrote:

Interesting, so shifting it an hour fixes it for you?

Reply to this email directly or view it on
GitHubhttps://github.com//pull/181#issuecomment-37116710
.

Reply to this email directly or view it on GitHubhttps://github.com//pull/181#issuecomment-37117030
.

[snicker]

I think that the cleanup can probably be reset to midnight... That
shouldn't ever lay between 1 and 2am (the problem hour)... It was one of
the squashed commits when I was testing. But why not 11:59pm because "think
different" Or whatever?

The hourly schedules will only go into effect if the exception is thrown
which would only happen one day of the year

[cantino]

Yea, I'm fine with the minutes change. I was wondering if the hourly
schedules should get reset the day after the time change, so that they
don't stay shifted for weeks until the Huginn instance is restarted.

On Saturday, March 8, 2014, snicker notifications@github.com wrote:

I think that the cleanup can probably be reset to midnight... That
shouldn't ever lay between 1 and 2am (the problem hour)... It was one of
the squashed commits when I was testing. But why not 11:59pm because "think
different" Or whatever?

The hourly schedules will only go into effect if the exception is thrown
which would only happen one day of the year

On Mar 8, 2014, at 18:26, Andrew Cantino <notifications@github.comjavascript:_e(%7B%7D,'cvml','notifications@github.com');>
wrote:

But do we need to restore to the normal schedule in a day or two?

On Saturday, March 8, 2014, snicker <notifications@github.comjavascript:_e(%7B%7D,'cvml','notifications@github.com');>
wrote:

Yup, that was the recommendation. TZInfo throws two diff exceptions,
there's probably another that needs to be monitored for "falling back"

On Mar 8, 2014, at 18:06, Andrew Cantino <notifications@github.comjavascript:_e(%7B%7D,'cvml','notifications@github.com');
<javascript:_e(%7B%7D,'cvml','notifications@github.comjavascript:_e(%7B%7D,'cvml','notifications@github.com');
');>>
wrote:

Interesting, so shifting it an hour fixes it for you?

Reply to this email directly or view it on
GitHubhttps://github.com//pull/181#issuecomment-37116710
.

Reply to this email directly or view it on GitHub<
https://github.com/cantino/huginn/pull/181#issuecomment-37117030>
.

Reply to this email directly or view it on
GitHubhttps://github.com//pull/181#issuecomment-37117062
.

Reply to this email directly or view it on GitHubhttps://github.com//pull/181#issuecomment-37119077
.

[snicker]

Ahh, I see.

I erroneously assumed that it would work itself out, but the application
would have to be restarted for that to happen.

I originally thought that the correction of such an error would really fall
in the scope of rufus-scheduler, and this is really more of a workaround.
You could implement a schedule to remove these schedules 24h later and
straighten it out...

[cantino]

At least on my system, everything is working okay now. We should still fix this for next year, but there's no rush. I'll look at this shortly :)

[0xdevalias]

Ping @cantino

[cantino]

Should be fixed by rufus-scheduler update: https://github.com/jmettraux/rufus-scheduler/blob/master/CHANGELOG.txt