The worst thing that I can imagine is that the compiled code works
properly on your development/staging environment but fails to work on
production. The nightmare starts when you just remember that you don't have
debugger on production. Here is what happened to me yesterday. I developed a web
service for the Time-Off time calculation. The code was excluding Ontario
statuary holidays. This service apparently without any external dependency was
working beautifully on my development laptop, but failing with some strange
error on the server.
Take a look at this code:
DateTime holiday =
DateTime.Parse("28/02/2008");
Sounds ok and works well on my Canadian computer (hey, it is made
in China but Windows regional options is set to English(Canada)). But the
very same line of code fails to run on an American machine. Simply because the
American version of this code should be like this:
DateTime holiday =
DateTime.Parse("02/28/2008");
That's just the date format but what can you do in a compiled code
for this? Aha, .NET Framework is the answer. If you read the time variable from
a Calendar or a DateTimePicker then the control is smart enough to do that, but
if you are reading a preformatted string or you are hard-coding the date in your
application then this issue come up. Here is the right way of solving this
problem:
using System;
using System.Globalization;
namespace DotNetKing
{
class
Program
{
static
void Main(string[]
args)
{
CultureInfo culture =
new CultureInfo("en-CA");
DateTime holiday =
DateTime.Parse("28/02/2008", culture);
Console.Write(holiday.ToString());
}
}
}
This way you not only hardcode the date but also hardcode the date culture, so
your code behaves Canadian even on an American server!
Cheers
Alireza