Here is the task for reference
https://issues.apache.org/jira/browse/OFBIZ-12864
Thanks & Regards
--
Deepak Dixit
ofbiz.apache.org
On Mon, Oct 30, 2023 at 6:33 PM Deepak Dixit <dee...@apache.org> wrote:
> The issue occurs when DST changes, and OFBiz fails to schedule recurring
> jobs properly.
> This is due to a condition in the PersistedServiceJob.createRecurrence
> method where it compares the next scheduled time (next) with the start time
> (startTime) for the job.
>
>
> *Proposed Solution:*To address the issue, adding a new field named
> JobSandbox.runTimeEpoch. This field would store the UTC epoch milliseconds
> of the runtime date.
> When scheduling or rescheduling recurring jobs, the system would use the
> UTC epoch stored in JobSandbox.runTimeEpoch for recurring job comparison.
>
> This solution ensures that the system uses a consistent, UTC-based time
> for scheduling and rescheduling recurring jobs, even when DST changes
> affect the local time.
>
> To implement this solution, we need to do following things:
>
> - Modify the PersistedServiceJob.createRecurrence method to calculate and
> store the UTC epoch milliseconds in the JobSandbox.runTimeEpoch field.
> - Update the code responsible for polling and rescheduling jobs to use the
> JobSandbox.runTimeEpoch field when it is set. If the field is not set, It
> would fall back to getting the runtime date to filter the jobs.
>
> By using this approach, the system should be able to handle recurring job
> scheduling more reliably, especially when DST changes are involved, as it
> ensures that all time comparisons are made in a consistent UTC format.
>
>
> Thanks & Regards
> --
> Deepak Dixit
> ofbiz.apache.org
>
>
> On Tue, Oct 17, 2023 at 11:00 AM Deepak Dixit <dee...@apache.org> wrote:
>
>> Hi Dev,
>>
>> I wanted to draw your attention to an issue we've encountered with the
>> OFBiz job scheduler, particularly when it comes to handling Daylight Saving
>> Time (DST) changes.
>>
>> It appears that the job scheduler fails to create new recurring jobs when
>> DST ends, especially when the tempExprTypeId is set to FREQUENCY (e.g., 15
>> minutes, 30 minutes).
>>
>> Upon further investigation, we've identified that the following condition
>> in PersistedServiceJob.createRecurrence might be the root of the issue:
>>
>> java
>>
>> if (next > startTime) {
>> // ...
>> // ...
>> }
>>
>> I'm curious to know if anyone else has encountered a similar problem or
>> if you have any insights to share regarding this issue.
>>
>> Thanks & Regards
>>
>> --
>> Deepak Dixit
>> ofbiz.apache.org
>>
>
