To get the calculated date, we need to add or subtract 86400000 (1000 * 60 * 60 * 24) milliseconds as one day equals to 86400000 milliseconds. One of such statements was failing on the day when daylight saving came to an effect. On these specific days, the day may have 23 hours or 25 hours. Particularly, in fall back from daylight saving, when the hours in the day is 25 hours, the new calculated date does not move forward and logic fails.
Now that I knew which custom function was responsible for this defect, I was easily able to build my logic around it to calculate the correct date. After applying the fix, the team tested all the possible scenarios to ensure no additional defect was introduced. With help from the testing team, we addressed the daylight saving issue within 6 hours. We were, therefore, able to deliver the invoices to our customers on time and not impact business operations.