Management went out and hired a Highly Paid Consultant to build some custom extensions for Service Now, a SaaS tool for IT operations management. HPC did their work, turned over the product, and vanished the instant the last check cleared. Matt was the blessed developer who was tasked with dealing with any bugs or feature requests.

Everything was fine for a few days, until the thirthieth of January. One of the end users attempted to set the “Due Date” for a hardware order to 03-FEB–2019. This failed, because "Start date cannot be in the past".

Now, at the time of this writing, Feburary 3rd, 2019 is not yet in the past, so Matt dug in to investigate.

function onChange(control, oldValue, newValue, isLoading) {
	if (isLoading /*|| newValue == ''*/) {
		return;
	}
	
	//Type appropriate comment here, and begin script below
	var currentDate = new Date();
	var selectedDate = new Date(g_form.getValue('date_for'));
	
	if (currentDate.getUTCDate() > selectedDate.getUTCDate() || currentDate.getUTCMonth() > selectedDate.getUTCMonth() || currentDate.getUTCFullYear() > selectedDate.getUTCFullYear()) {
		g_form.addErrorMessage("Start date cannot be in the past.");
		g_form.clearValue('date_for');
	}
}

The validation rule at the end pretty much sums it up. They check each part of the date to see if a date is in the future. So 05-JUN–2019 obviously comes well before 09-JAN–2019. 21-JAN–2020 is well before 01-JUL–2019. Of course, 01-JUL-2019 is also before 21-JAN-2020, because this type of date comparison isn't actually orderable at all.

How could this code be wrong? It’s just common sense, obviously.

Speaking of common sense, Matt replaced that check with if (currentDate > selectedDate) and got ready for the next landmine left by the HPC.