Bug #51051 for Schedule-Cron: DST issue

Mon Nov 02 16:21:19 2009 joseph.shin [...] boards2go.com - Ticket created

Subject:

DST issue

Ran into weird behavior for DST. The cron looked like 0 1 1 * * , but from 1AM - 2AM, the job fired off probably 6,000 times :). I would have expected one of the 2 behaviors identified in the DST section. Any help would be appreciated.

Thu Jan 07 06:17:04 2010 roland [...] cpan.org - Correspondence added

Hi,

On Mon Nov 02 16:21:19 2009, joeshin wrote:
Show quoted text

> Ran into weird behavior for DST. The cron looked like 0 1 1 * * , but
> from 1AM - 2AM, the job fired off probably 6,000 times :). I would have
> expected one of the 2 behaviors identified in the DST section. Any help
> would be appreciated.

sorry for delay, the ticket slipped through somehow (and I didn't received a mail
in my inbox).

Could you please tell me which version of Schedule::Cron do you use ?

Version 0.99 fixes a serious bug concerning DST. From the man page:

DST ISSUES
Daylight saving occurs typically twice a year: In the first switch, one hour is skipped. Any job which which triggers in this skipped
hour will be fired in the next hour. So, when the DST switch goes from 2:00 to 3:00 a job would is scheduled for 2:43, then it will be
executed at 3:43.

For the reverse backwards switch later in the year, the behaviour is undefined. Two possible behaviours can occur: For jobs triggered in
short intervals, where the next execution time would fire in the extra hour as well, the job could be executed again or skipped in this
extra hour. Currently, running "Schedule::Cron" in "MET" would skip the extra job, in "PST8PDT" it would execute a second time. The rea-
son is the way how Time::ParseDate calculates epoch times for dates given like "02:50:00 2009/10/25". Should it return the seconds since
1970 for this time happening 'first', or for this time in the extra hour ? As it turns out, Time::ParseDate returns the epoch time of
the first occurence for "PST8PDT" and for "MET" it returns the second occurence. Unfortunately, there is no way to specify which entry
Time::ParseDate should pick (until now). Of course, after all, this is obviously not Time::ParseDate's fault, since a simple date speci-
fication within the DST backswitch period is ambigious. However, it would be nice if the parsing behaviour of Time::ParseDate would be
consistent across time zones (a ticket has be raised for fixing this). Then Schedule::Cron's behaviour within a DST backward switch
would be consistent as well.

Since changing the internal algorithm which worked now for over ten years would be too risky and I don't see any simple solution for
this right now, it is likely that this undefined behaviour will exist for some time. Maybe some hero is coming along and will fix this,
but this is probably not me ;-)

Sorry for that.

I know, this is not a perfect solution, but at least Schedule::Cron shouldn't run amok anymore. Sorry for any inconvenience.
Please let me know, whether I can close the ticket (which I assume, when you don't veto within the next two weeks ;-)

...roland

Thu Jan 07 06:17:06 2010 The RT System itself - Status changed from 'new' to 'open'

Thu Jan 07 11:53:56 2010 joseph.shin [...] boards2go.com - Correspondence added

From:

joseph.shin [...] boards2go.com

Roland, We are currently using v1.16.  I have read that and it says *some* undefined behavior... but this was unexpected :)  I will take some time to think about a solution. Thanks, Joseph Shin On Thu Jan 07 06:17:04 2010, ROLAND wrote: > Hi, > > On Mon Nov 02 16:21:19 2009, joeshin wrote: > > Ran into weird behavior for DST. The cron looked like 0 1 1 * * , > but > > from 1AM - 2AM, the job fired off probably 6,000 times :). I would > have > > expected one of the 2 behaviors identified in the DST section. Any > help > > would be appreciated. > > sorry for delay, the ticket slipped through somehow (and I didn't > received a > mail > in my inbox). > > Could you please tell me which version of Schedule::Cron do you use ? > > Version 0.99 fixes a serious bug concerning DST. From the man page: > > DST ISSUES > Daylight saving occurs typically twice a year: In the first > switch, one hour is skipped. Any job which which triggers in this > skipped > hour will be fired in the next hour. So, when the DST switch > goes from 2:00 to 3:00 a job would is scheduled for 2:43, then it will > be > executed at 3:43. > > For the reverse backwards switch later in the year, the > behaviour is undefined. Two possible behaviours can occur: For jobs > triggered in > short intervals, where the next execution time would fire in > the extra hour as well, the job could be executed again or skipped in > this > extra hour. Currently, running "Schedule::Cron" in "MET" would > skip the extra job, in "PST8PDT" it would execute a second time. The > rea- > son is the way how Time::ParseDate calculates epoch times for > dates given like "02:50:00 2009/10/25". Should it return the seconds > since > 1970 for this time happening 'first', or for this time in the > extra hour ? As it turns out, Time::ParseDate returns the epoch time > of > the first occurence for "PST8PDT" and for "MET" it returns the > second occurence. Unfortunately, there is no way to specify which > entry > Time::ParseDate should pick (until now). Of course, after all, > this is obviously not Time::ParseDate's fault, since a simple date > speci- > fication within the DST backswitch period is ambigious. > However, it would be nice if the parsing behaviour of Time::ParseDate > would be > consistent across time zones (a ticket has be raised for fixing > this). Then Schedule::Cron's behaviour within a DST backward switch > would be consistent as well. > > Since changing the internal algorithm which worked now for over > ten years would be too risky and I don't see any simple solution for > this right now, it is likely that this undefined behaviour will > exist for some time. Maybe some hero is coming along and will fix > this, > but this is probably not me ;-) > > Sorry for that. > > > I know, this is not a perfect solution, but at least Schedule::Cron > shouldn't > run amok anymore. Sorry for any inconvenience. > Please let me know, whether I can close the ticket (which I assume, > when you > don't veto within the next two weeks ;-) > > ...roland

Thu Jan 07 12:00:46 2010 joseph.shin [...] boards2go.com - Correspondence added

From:

joseph.shin [...] boards2go.com

wow too early in the morning... we are indeed using v.97 will update to v.99 :)

Fri May 14 13:29:04 2010 roland [...] cpan.org - Correspondence added

I released 1.00 this morning. Do you still have the problem with DST switching ?

Please tell me within the next two weeks,
whether I can help you out, otherwise I will close this ticket.

thanx ...
...roland

On Thu Jan 07 12:00:46 2010, joeshin wrote:
Show quoted text

> wow too early in the morning... we are indeed using v.97 will update
> to v.99 :)

Fri May 14 13:29:09 2010 roland [...] cpan.org - Taken

Fri May 14 13:35:56 2010 joseph.shin [...] boards2go.com - Correspondence added

From:

joseph.shin [...] boards2go.com

Roland, Last DST switch all went smooth with version .99 Much appreciated, feel free to close this one :) Joe On Fri May 14 13:29:04 2010, ROLAND wrote: Show quoted text

> I released 1.00 this morning. Do you still have the problem with DST > switching > ? > > Please tell me within the next two weeks, > whether I can help you out, otherwise I will close this ticket. > > thanx ... > ...roland > > On Thu Jan 07 12:00:46 2010, joeshin wrote:

> > wow too early in the morning... we are indeed using v.97 will update > > to v.99 :)

Mon May 17 02:02:17 2010 roland [...] cpan.org - Correspondence added

seems to be fixed.

Mon May 17 02:02:20 2010 roland [...] cpan.org - Status changed from 'open' to 'resolved'