Email RFC's

When creating or manipulating emails, either by creating a Pop3 library or talking directly to a smtp server, its always useful to know where to look for those useful RFC's that help you find out how to decode that particular field, how MIME should be implemented and so forth.

I found the following list somewhere on the internet, and here it is again mostly for my own sake, since I use them a lot:

RFC description status
RFC 1939 POP3 protocol Updated by RFC 2449
RFC 2449 POP3 Extension Mechanism  
RFC 822 STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES Obsoleted by RFC 2822
RFC 2822 Internet Message Format  
RFC 2045 MIME Part One: Format of Internet Message Bodies Updated by RFC 2231
RFC 2046 MIME Part Two: Media Types  
RFC 2047 MIME Part Three: Message Header Extensions for Non-ASCII Text Updated by RFC 2231
RFC 2183 The Content-Disposition Header Field Updated by RFC 2231
RFC 2231 MIME Parameter Value and Encoded Word Extensions: Character Sets,...  
RFC 2387 The MIME Multipart/Related Content-type  
RFC 3462 The MIME Multipart/Report Content-type  
RFC 2111 Content-ID and Message-ID Uniform Resource Locators  
RFC 2632 S/MIME Version 3 Certificate Handling  
RFC 2633 S/MIME Version 3 Message Specification  
RFC 2821 Simple Mail Transfer Protocol  

.NET TimeZone

Everyone working with .NET and TimeZones have at one point thought, why the #%&#&% can't I instantiate another TimeZone than the current one, i.e. why is it not possible to create a .NET TimeZone object in the following simple way.

TimeZone zone = new TimeZone("Europe/Copenhagen");

TimeZone zone = new TimeZone("CET");

It seems like Microsoft did not think of, or decided not to implement multi timezone support in .NET, and thats too bad, because Timezone handling, Daylight savings are just a bitch to work with.

Timezones are not so bad, since its pretty easy to identify what timezone a given country is in. There are numerous sources for this on the internet, such as http://www.timeanddate.com/worldclock/, and with a little manual work, or a little screen scraping you can have a combined country/timezone list in no time.

The real problems occurs when you want to find out whether or not a given TimeDate object is within the Daylight savings time for a given country and timezone, and in that, the timezone are of no use, since it says nothing about the daylight savings of the date.

I have tried some solutions where I try to identify the daylight savings time for the most used countries, for a few years in advance, but that won't help me with dates in the past, and is really not a good solution, since the completeness of the solution is at best lacking.

I have searched a lot of places on the internet for a proper solution, and someone have made a solution for retrieving the timezones from the windows registry combined with some dll imports fromt he win32 API, but those are not perfect either.

So having almost tossed the towel into the ring, I stumpled upon another page on the internet http://www.codeplex.com/publicdomain/, and I thought, hmm, another crappy implementation, but no, its a full .NET implementation of the tz database http://www.twinsun.com/tz/tz-link.htm. I had looked at that timezone database myself a few times, but the sheer size and format of the database was just such a daunting task, that I have never fathomed to even be able to read that into a sensible .NET format.

The .NET library called PublicDomain is very easy to work with, much intuitive, and handles timezones and daylight savings very nice.

Its as simple as:

// Get the local computer's time zone
TzTimeZone dkZone = TzTimeZone.GetTimeZone("Europe/Copenhagen");

TzTimeZone ausZone = TzTimeZone.GetTimeZone("Australia/Adelaide");

DateTime dkNow = DateTime.UtcNow; //When in danish timezone

DateTime auzNow = ausZone.ToLocalTime(dkNow);
Gracefully right :)

Too bad Microsoft did not implement this.

The good part is that they will in .NET 3.5. I'm not sure of the extend of the implementation, or how well the daylight saving rules for each country is implemented, but at least its good that Microsoft at least have started looking in this direction.