The .NET framework did not offer anything to make this easy. Only one timezone could be constructed: the system one.
His original plan was to implement Mono.ExtendedTimeZone that would be a derived class from the TimeZone class in the framework but that would be populated from some other database.
He considered a few choices and discussed:
- Use libc in some form, to pull the data out of it (external program) and create the instances of the timezone as needed. This could be slow due to using an external program with a temporary TZ setting.
- Parse the libc datafiles, very OS/distribution-specific.
- Ship our own databases.
We did not want to go into the business of maintaining the timezone files and redistribute Mono updates every time new countries were created or rules changed, so we opted for dumping the data out of libc in some form.
Stephane ended up parsing the GNU libc datafiles: they did not depend on external programs, works on Linux easily and is fast. This will require the code to be ported to other platforms though.
Around that time we discovered that Orcas (.NET 3.5) included a class to cope with this problem in the form of System.TimeZoneInfo in the System.Core.dll assembly. So his API effort changed from implementing a Mono.ExtendedTimeZone to implement System.TimeZoneInfo. Yesterday he emailed me the above screenshot and we got the code commited to SVN.
Check Stephane's PicasaWeb album it contains various screenshots of his F-Spot work.