AzureFunctions, DateTime.Now and why CultureInfo matters

This post maybe is only for myself to finally remember the differences between on-premises and cloud in terms of environment variables. I’m currently working on some features for MoCaDeSyMo that are based on AzureFunctions and Visual Studio 2017. Since one of the previews, you are now allowed to build your own custom libraries and use them in an AzureFunctions project. Furthermore, you can now easily test and run your AzureFunction on your local computer. That’s a huge deal compared to publish the function every time or compared to the time you need to attach the remote debugger to your function running in the cloud. So for the last couple of days I only tested my function locally and of course, everything worked fine. After publishing it I got a 500 internal server error back. Ok, nothing new, something is different between local and cloud. So let’s find the difference. Turns out there is a new version of the AzureFunction tooling in VS so I updated this. After some hours I got to the point that something is messing around with my connection to the Azure storage table I use. Still, everything works fine when tested locally but now I get a 400 bad request back from the Azure storage table. Now only remote debugging can help and by the way that’s a damn cool thing if you think of it. Debugging your cloud function locally. Nevertheless, turns out that the bug is somewhere in those lines of code: Again, everything works perfectly on my local machine but crashes somewhere here when published to the cloud. The experienced guys maybe solve it within the blink of an eye, but it took several hours for me.  The difference is the result you get back from DateTime.Now.Date.ToShortDateString(). My AzureFunctions run somewhere in the US, with an us-US CultureInfo as base culture for the current thread. On my local machine, the base CultureInfo is de-AT so in terms of date, the difference is obviously MM/dd/yyyy versus dd.MM.yyyy. That’s the “only” difference in terms of the code. At first, I was like, ok that’s not a big deal, I can handle that different date format in the database and I don’t care if my dev tables get mixed up with different formats.    But turns out there is a list of characters you are not allowed to use in a RowKey column in an Azure storage table. And of course, “/” is one of them.  So the code worked fine in a de-AT environment because of the dd.MM.yyyy but crashed in an us-US one where the format is MM/dd/yyyy.  Sometimes the smallest things you already know come back and haunt you for hours …