TryParseExact and UTC DateTime

I’m in the midst of SIP-land at the moment and looking at the expiry time of requests. After discovering a subtle difference in the parsing of DateTime strings between my development machine and the production servers, we’re now using the DateTime.TryParseExact() method to specify exactly what the service should expect to see.

One of the parameters allows you to specify a DateTimeStyle and as I knew the time was going to be in UTC time I chose the AssumeUniversal DateTimeStyle. The MSDN information for DateTimeStyle defines AssumeUniversal indicating

“that if no time zone is specified in the parsed string, the string is assumed to denote a Coordinated Universal Time (UTC). Cannot be used with AssumeLocal or RoundtripKind.”

It seemed to be exactly what I wanted until I started testing it. The time I was getting back was an hour ahead so it was being converted to local time as we’re currently in British Summer Time (GMT+1) here.

The solution was to use the AdjustToUniversal DateTimeStyle instead. I’ve tested this with my system time in British Summer Time and without the local adjustment and it works fine for both.

Here’s the small console application I wrote to test the TryParseExact() method. Try it with AssumeUniversal instead of AdjustToUniversal if you want to see the difference for yourself.

class Program
{
static void Main(string[] args)
{
DateTime requestExpires;
DateTime.TryParseExact("23/05/2008 08:30:49", "dd/MM/yyyy HH:mm:ss", null, DateTimeStyles.AdjustToUniversal, out requestExpires);
Console.WriteLine(requestExpires);
Console.ReadLine();
}
}

New iPhones ahoy?

The recent news that the 8Gb version of the iPhone was discounted wasn’t a huge shock with rumours of a pending 3G / Business flavoured iPhone in the distance.  However, today sees MacRumours reporting that O2 have stopped selling ANY iPhones, 8Gb or 16Gb.

Sales might have been lighter than they anticipated, due to the lack of 3G maybe, but to stop selling it altogether? Surely this points at the suspected release date for the updated iPhone of June being brought forward a lot sooner?

I know personally that I’ve been waiting for this refresh, partially fuelled by the development work I’ve been doing on the iPhone SDK which will allow applications to be deployed on this version of the firmware, and the improved feature set including 3G.

I hope they’ll also keep the prices keen if they’re wanting businesses to take them up as serious alternatives to RIM. After having used a Blackberry for my on-call support duties, I know I’d much rather interact with an iPhone any day.

So, keep your ears to the ground and hopefully we’ll see a brand new iPhone very very shortly.

SourceSafe: “Only one database connection at a time is supported.”

I’ve been having intermittent problems with Visual Studio 2005 and SourceSafe 2005 occasionally complaining that “Only one database connection at a time is supported” when I load up solutions with multiple projects in them.

A Microsoft Knowledge-base article pointed me to the potential problem. Looking in the mssccprj.scc files for  both .csproj files loaded in the solution, I spotted one of them had an extra entry for a .sln file as well as the .csproj file. Both of the SCC_Aux_Path variables for the .csproj definitions were the same so the knowledge-base fix wasn’t quite correct.

Removing the definition for the .sln file from the mssccprj.scc file has helped remove this problem. Saves doing the usual suggestion of ‘SourceSafe is screwed on your machine, you should get it reinstalled’.