How unit tests and CI saved me from a world of pain

I recently had to fix a bug in an older codebase that did not follow the best practices when handling date times. In short, every Date Time in the application was expecting / using an EST date time since the project was traditionally deployed on-prem.

With the move to Azure, dates no longer defaulted to EST and since it wasn’t feasible to convert the entire codebase to properly use UTC, I had to update my code to use EST.

Having done this before, years ago, I quickly whipped up some code to convert an UTC date to EST:

public static DateTime ToEST(this DateTime date)
{
    if (dateUtc.Kind == DateTimeKind.Unpecified)
         throw new ArgumentOutOfRangeException(nameof(date),"Input Date Time must contain TimeZone information.");
    var easternZone = TimeZoneInfo.FindSystemTimeZoneById("Eastern Standard Time");
    return TimeZoneInfo.ConvertTimeFromUtc(timeUtc, easternZone);
}

This seems a pretty benign piece of code, that I’ve used successfully in the past and it all tested nicely locally however once I pushed my code in the build failed.

To add a bit more context, and probably reveal the problem to the experienced eye, this code is part of an .NET Core API project that gets deployed in an Azure Web App running on a Linux App Service plan. Our Continuous Integration pipeline run on an Ubuntu Azure hosted agent. So when the tests ran in the CI environment, they ran in Linux and, you guessed it, Linux does know have a TimeZone with the “Eastern Standard Time” id. On Linux, it’s “America/New_York” or “America/Toronto” - which I found in 5 minutes using our friend, The Internet, making this a relatively painless fix and a teachable moment for me.

Just imagine, not having that CI and unit tests, and have this “randomly” crash in the QA environment, the hours of frustration trying to debug this.

To recap, there were a couple things that saved me that day. First, the fact that we invested the time to put a unit testing framework in place, that allowed me, the developer, to quickly and painlessly add a couple of unit tests to my project and second, the fact that we have an automated build pipeline that runs those unit tests in a similar environment to our real environments.