Premium support for our pure JavaScript UI components


Post by takafumi ohtake »

Hi Bryntum support,

I found nonworking time is incorrect when timezone is America/Santiago.
Maybe, summertime affects the bug.

[How to reproduce]

  • Set OS timezone to America/Santiago.
  • Open the advanced demo. https://bryntum.com/products/gantt/examples/advanced/
  • Execute the code below.
    gantt.project.calendar.clearIntervals();
    gantt.project.calendar.addIntervals({
       "recurrentStartDate": "on Sat",
       "recurrentEndDate": "on Sun",
       "isWorking": false
    });
    

[Expected]

  • Only Saturday is nonworking day

[Observed]

  • April is nonworking day in addition to Saturday

Please see the video for details.

incorrect_working_time.mp4
(2.47 MiB) Downloaded 62 times

Our customer is in big trouble with this bug.
Could you please provide us with a workaround?


Post by alex.l »

Thanks for the report! I've opened a ticket for that here https://github.com/bryntum/support/issues/5964
And asked our dev team to assist for a workaround, if that will be possible.
We will let you know asap.

All the best,
Alex


Post by alex.l »

That's because of DST shift. No date available on period specified in the rule, so it takes next one and this artefact appears.
As a workaround, you could try to extract this data from recurring rule and handle it manually.

As example, use these non working periods:

 "recurrentStartDate": "on Sat before 2019-04-06T00:00:00",
   "recurrentEndDate": "on Sun before 2019-04-06T00:00:00",
   
"startDate": "2019-04-06T00:00:00", "endDate": "2019-04-06T23:00:00",
"recurrentStartDate": "on Sat after 2019-04-07T00:00:00", "recurrentEndDate": "on Sun after 2019-04-07T00:00:00",

All the best,
Alex


Post by alex.l »

Nevermind the above. Here is a better workaround. Change end date rule with this:

gantt.project.calendar.clearIntervals();
gantt.project.calendar.addIntervals({
   "recurrentStartDate": "on Sat",
   "recurrentEndDate": "EOD",
   "isWorking": false
});

EOD - end of day.

It's not documented, but good for a workaround.

All the best,
Alex


Post by takafumi ohtake »

Hi Alex,

Thank you for the workaround.
I'll try it.

Regards,
Takafumi


Post by nickolay »

@takafumi ohtake Hi, this issue will be resolved soon (for the particular America/Santiago timezone). Unfortunately, the nature of date/time implementation in the JS makes it hard to implement a generic solution for all timezones (and we also rely on the "later.js" library which does not process DST shifts well either), but we'll be rolling out fixes on per case basis - so if you'll find another DST issue, please let us know.

One more workaround is available - if one specifies time in the recurrent interval:

gantt.project.calendar.clearIntervals();
gantt.project.calendar.addIntervals({
   "recurrentStartDate": "on Sat at 00:00",
   "recurrentEndDate": "on Sun at 00:00",
   "isWorking": false
});

"later.js" switches internally to another code path, which is not affected by this issue.


Post by takafumi ohtake »

Hi nicolay,

Thank you for your reply.
Honestly speaking, I investigated the later.js code. And I patched to the later.js by myself.
I think the later.compile.tick should be like the below.

    tick: function (dir, date) {
      // fix the bug when the DST is changed
      let newTick;
      if (dir === "next") {
        const spanEnd = tickConstraint.end(date);
        newTick = new Date(spanEnd.getTime() + later.SEC);
        const timezoneDiff = newTick.getTimezoneOffset() - spanEnd.getTimezoneOffset();
        if (timezoneDiff > 0) {
          newTick = new Date(newTick.getTime() + timezoneDiff * 60 * 1000);
        }
      } else {
        const spanStart = tickConstraint.start(date);
        newTick = new Date(spanStart.getTime() - later.SEC);
        const timezoneDiff = newTick.getTimezoneOffset() - spanStart.getTimezoneOffset();
        if (timezoneDiff < 0) {
          newTick = new Date(spanStart.getTime() + timezoneDiff * 60 * 1000);
        }
      }

  return newTick;
}

Post by nickolay »

Thanks for sharing the code! I've also patched this method, but used a bit different approach - will compare it with this one.


Post Reply