Daylight Savings Time

Introduction

Daylight Savings Time (DST) is nearly at an end: on Sunday, November 7, 2021, everyone's clock will roll back one hour (or at least, everyone whose time zone observes DST in the first place). Any smart clocks that update automatically will go from 1:59 am back to 1:00 am, and all your other clocks will be ahead for another few days until you realize you forgot about the microwave.

It will also affect the clocks in our software, but the system can largely take care of that for you. The UI already converts the time zone from your company settings into Coordinated Universal Time (UTC). We switch to UTC because it's universally accepted within the software industry. Upon daylight savings time, our UI will automatically adjust for you.

How does my time zone differ from UTC?
UTC in a time zone that goes through the United Kingdom, Portugal, and and several west African nations like Côte d'Ivoire, Ghana, and Senegal. The timekeepers of the world have decided that UTC will be the center, and other time zones are based off it. Time zones to the east will add hours onto UTC; time zones to the west will subtract them. For instance, LoanPro is headquartered in the Mountain Standard Time zone (MST), which is seven hours west of UTC — this is represented as UTC-07:00.

Although our local time zone switches between standard and daylight savings time, UTC never observes daylight savings. So, for part of the year, MST becomes Mountain Daylight Time (MDT), only six hours less than UTC. MDT can also be represented as UTC-06:00.

In short, time zones in the western hemisphere are several hours behind UTC. When they observe DST, they are closer to UTC, and when they go back off DST, they're farther off again.

By and large, LoanPro does not perform many operations based off of hour of the day, however, there are two specific areas that hour of the day does come into factor:

  • AutoPays
  • NACHA Batch Cutoff times

We'd like to dive deeper into those two areas to help you better understand how LoanPro handles DST for those features.

AutoPays

To figure out if an AutoPay will be affected by the switch, you'll need to answer two questions:

  1. Was this AutoPay set up through the UI or API? If it was through the UI, you're good — end of story. The UI automatically converts that time into UTC, and will automatically convert the time to non-DST on the 7th.
  2. Was the AutoPay was set up through the API before Nov. 7, but with the "processDateTime" field after Nov. 7? If this is the case for you, then it may not even need to be updated. The only thing you'll need to be aware of is that LoanPro accepted your API call, and created the AutoPay with the UTC time that was specified in the call. So if your integration and API call does not adjust and account for DST, then the AutoPay that was created with the API call was likely created with a different hour then you were expecting, due to UTC remaining constant and DST changing the time.

For instance, let's say an AutoPay was created via the API sometime in October, and the first AutoPay process date/time is 5:00 pm, on November 7. When DST changes your tenant timezone, the system will update to fall back an hour, the AutoPay would end up processing an hour early, at 4:00 pm local time. In most cases, this won't be a major issue, but depending on when your payment processors close off batches, it could mean that a payment comes in a day earlier than expected. (In the circumstance that it moves from 12:00 AM to 11:00 PM on the day prior).

If needed, how can I correct the times for AutoPays?

This has to be done loan by loan, whether through the UI or API. If you're editing through the UI, it'll be the same process as Creating and Editing AutoPays, and you'll just need to edit the Advanced setting of "Process Time".

Through the API, you'll send a PUT request to the endpoint for the specific loan:

PUT https://loanpro.simnang.com/api/public/api/1/odata.svc/Loans(9100)

The payload will include the AutoPay ID (225 in this example):

{
"Autopays": {
"results": [
{
"__update": true,
"id": 225,
"processDateTime": "2021-11-04 19:00:00"
}
]
}
}

The field "processDateTime" is a string, formatted "YYYY-MM-DD HH:MM:SS". The time is in UTC time, explained in more detail below. Additionally, if you would like help identifying or correcting these AutoPays, feel free to reach out to our support team and we can help with an update via a support job.

Cutoff Times for NACHA Batches

NACHA payment processors batch payments together every day, and each processor has a specific cutoff time determining when to compile the payments from the last 24 hours into a NACHA file. These cutoff times are saved in UTC. If your cutoff time is set to 07:00 UTC, the payments from 7:00 am to 6:59 am the next day will all be in the same batch. Because cutoff times are saved in UTC, you'll need to either move the cutoff time back by one hour in order to maintain the same cutoff time post-DST. This is a one time process, and can be done either manually via the UI, or via an API call.

How can I change batch cutoff times in the UI?

Log into Secure Payments, and navigate to Settings > Processors > Bank Account/ACH (USA) > NACHA Batch Submission. From here, you'll see a list of all your NACHA processors.

Click the pencil icon to edit a processor, and then change move the cutoff time back one hour. If your cutoff time was 6:30 UTC, you'll want to change it to 5:30 UTC.

How can I change batch cutoff times through the API?

You can change a NACHA processor's cutoff time with a relatively simple PUT request. You'll need each processor's ID, which can be found with a GET request.

Getting the Processor IDs and Cutoff Times

You can find the ID and cutoff time for each processor with a GET request.

GET https://securepayments.loanpro.io/api/processors/nacha

Here's a sample response:

[
{
"discretionary_data": "none",
"name": "AFCU ",
"cutoff_time": "05:30",
"bank_name": "AMERICA FIRST",
"company_name": "Enron",
"tax_id": "324079444",
"id": 765,
"merge_similar_tx": false,
"export_type": "csv",
"bank_routing": "324377516"
},
{
"discretionary_data": "Accounts are numbered",
"name": "Fancy New Processor",
"cutoff_time": "07:45",
"bank_name": "WELLS FARGO BANK",
"company_name": "Prime Lending",
"tax_id": "275456262",
"id": 835,
"merge_similar_tx": false,
"export_type": "csv",
"bank_routing": "026012881"
},
{
"discretionary_data": "Accounts are numbered",
"name": "NACHA Libre",
"cutoff_time": "07:45",
"bank_name": "WELLS FARGO BANK",
"company_name": "Prime Lending",
"tax_id": "275456262",
"id": 846,
"merge_similar_tx": false,
"export_type": "none",
"bank_routing": "026012881"
}
]

The important fields here are

  • "id" – The processor ID, used in the endpoint of your PUT request
  • "cutoff_time" – The current UTC cutoff time for each processor.

Then, you'll the processor ID in the endpoint of a PUT request:

PUT https://securepayments.loanpro.io/api/processors/nacha/765

The payload will include the new cutoff time in UTC:

{
"nacha": {
"cutoff_time": "05:30"
}
}

The 200 response will just say that it was a success:

{
"result": true
}

Remind me why we deal with daylight savings time in the first place?
The main idea is saving energy. If we schedule our days so that we can use natural, free sunlight for most activities and use electric lighting for less time, we'll end up saving a lot of power without spending anything.


How did we do?


Powered by HelpDocs (opens in a new tab)