Thanks Scott for the review and input. I agree we can use UTC, but in this case we need to reschedule the job timings according to the user timezone. eg. - Reporting jobs that runs on specific time - Some business process, like order routing job etc. that should run on specific time,
Please correct me if I am missing something? Thanks & Regards -- Deepak Dixit ofbiz.apache.org On Fri, Nov 3, 2023 at 2:38 PM Scott Gray <[email protected]> wrote: > Hi Deepak, > > IMO the best general solution is to not run OFBiz or the database > configured with a timezone that observes DST, instead use UTC or similar. > This achieves the same result but without needing any extra fields. > > I'm not objecting to your solution, just sharing this tip out loud since > the JobSandbox is only one of many places that can have trouble with > ambiguous DST date/times and it is very difficult to change timezone at the > db level once it's filled with production data. > > Regards > Scott > > On Mon, 30 Oct 2023 at 13:05, Deepak Dixit <[email protected]> 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 <[email protected]> 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 > > > > > >
