Re: Ah, VB ... "variants"
Another VB horror I had to sort out.
A developer writes a critical routine that takes a datetime parameter. This routine eventually gets called from hundreds of locations all over the system. Often it's actually passed a datetime value, but sometimes it gets a variant and sometimes it just gets a string. VB says "that's cool, just pass any old thing and I'll make it work".
Years pass, and it starts to become clear that there are some bad dates in the system. It turns out that VB's way of turning strings into dates is to ignore the system locale and try to guess what the format might be. Pass in "25/12/2015" and it correctly assumes DMY and returns 25 December, but when it sees "10/12/2015" it returns 12 October! Finding the bad calls is more or less impossible, given the lack of VB code analysis tools.
The cause of this problem is a thing called cdate() that lives deep inside the run-time infrastructure. It turns out that the only way to fix it is to add code that patches the run-time after it's loaded into memory, not something you really want to do on a mission-critical server.
Thank you, Microsoft.