Daylight Saving Effects on Date Calculations in NetSuite Advanced PDF-HTML Templates
The effects a change in time plays in code isn’t always top of mind when building out a new system. Late last year, Smartbridge had to attend to the issues that daylight saving caused with date calculations in our invoicing system.
Recently, we were hit by an issue related to the daylight saving time change. This issue caused our invoice forms to fall apart. Everything was behaving weird and no one had any idea what was happening!
Smartbridge invoices display data in various groups such as by resource, billable/non-billable items, weeks, etc. All formatting based on groups was disorganized due to this issue such as the invoices not being grouped correctly or records were sometimes printed multiple times. Also, billing total/sub-totals were not correct.
We had to fix this issue as soon as possible as this was affecting the billing cycle for the company and all invoices needed to be delivered to the customers the following day. I was under pressure to address the issue as soon as possible so as not to impact business operations. I immediately started looking into the issue by first logging a call with NetSuite support. I then debugged the Forms code with a support analyst but could not find anything wrong.
As I mentioned in my earlier blog post, Advanced PDF-HTML Development in NetSuite, dividing the code into multiple sections and the use of functions eases a developer’s life. And it was true in this case as well. The code logic was divided into various custom functions which allowed me to more easily isolate the issue. I was therefore able to quickly identify the defective custom functions used in different sections of the invoice form.
After debugging the code, I found that the logic to calculate start dates and end dates was not yielding the desired results. The cause was that there is no direct function available in FreeMarker to add/subtract days from a date. I was using code similar to the following statement:
<#local week_end = (date?date?long + (6 * 86400000))?number_to_date?string(“MM/dd/yyyy”) />
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.
Looking for more on Systems Modernization?
Explore more insights and expertise at smartbridge.com/modernization
Keep Reading: Advanced PDF-HTML Development in NetSuite
There’s more to explore at Smartbridge.com!
Sign up to be notified when we publish articles, news, videos and more!
Other ways to
follow us:
