That is a fair criticism, however in its defense, the added functionality in the package only adds a few hundred Kb to the size of the DLL, so I do not understand the claim that non-TZ related code "detracts from it's acceptance from a broad spectrum of .NET users." Have you queried a broad spectrum/sample of .NET users? The reason I think it is worth mentioning on the main page is that there is no alternative, other than what Microsoft provides (as you mention, the latest incarnation simply rounds a few edges, but makes no significant advancements). The sole reason why I created this package was because I could not find such a package. Being in my shoes before I created it, I would not care that it contained other code. Since all of the code is in the PublicDomain, it would also be trivial for me to take out the TZ related code (a few source files), and either build my own package or simply insert the code files into my existing project. However, as developer of the package, I will not create a separate packaging of PublicDomain just to advance such a "pure" implementation. I do not want to shatter code, and create intricate co-dependencies, which defeats the purpose of the package as a milieu of simple-to-use .NET code. As for the name of the package, well I can't disagree with you, but I don't think that it detract from the usefulness of propagating the olson database throughout the .NET. The net of my defense against the arguments of package size and naming is that fundamentally it solves a problem that exists today -- lack of olson database support in .NET. This severely impacts interoperability, correctness, and functionality. Thanks for the consideration On 8/23/07, Phillip Guerra <Phillip.Guerra@nkch.org> wrote:

When last I reviewed this package, it included a variety of librairies, not just the tz implementation. In my opinion, this detracts from it's acceptance from a broad spectrum of .Net users. There is alos criticism of the library name 'PublicDomain' as not being descriptive of the contents of the library.

Now, I've not used the library, but after my initial review, I would not be an adopter of this particular implementation. I'm not sure if it should be the .Net defacto implementation. However, in fairness to the developer, it's a start for folks wondering about how to go about this tz integration in a .Net MS world. The lastest MS implementation of timezone information builds upon the already flawed practice of storing information in the registry. Although, the data structures improved a bit, this implementation still leave a lot to be desired.

-----Original Message----- From: Kevin [mailto:hellosticky@gmail.com] Sent: Sunday, August 19, 2007 4:55 PM To: tz@lecserver.nci.nih.gov Subject: C#/VB.NET PublicDomain Olson Time Zone Database Implementation

Hi,

I created a fully Public Domain .NET library which implements the Olson time zone database for .NET applications. The package is called PublicDomain and the source, binaries, and documentation are available at http://www.codeplex.com/PublicDomain. Olson time zone database support is just one part of a larger package of various pieces of public domain code. The package was written from scratch in C# and includes an objectified form of the olson time zone database (because we all know how fun it is to analyze the raw, obfuscated data). I also created a variety of unit and regression tests.

The implementation used to be quite experimental, but now it has gone through a bit of usage and appears to be getting quite solid. I also wrote an article on codeproject discussing a simple use case of using the package (http://www.codeproject.com/useritems/Using_time_zones_in_NET.asp).

I would appreciate it if you included a description of this package for those that use .NET, including C#, VB.NET, etc. on the Olson Time zone database home page (http://www.twinsun.com/tz/tz-link.htm) -- using some form of less verbose description than mine above :-).

Thanks! Kevin

Confidentiality Notice: This email message, including any attachments, is for the sole use of the intended recipient(s), and may contain privileged or confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by replying to this email, and destroy all copies of the original message.

Hi Phillip, There is no need to apologize, I completely understand your point of view, and I'm sure it is shared by many.

I'm not saying that your package is not helpful. I'm just voicing my feelings about it becoming adopted as a .Net standard for the Olson TZ information.

Perhaps this is where some of our disagreements stem from. I was not advocating this implementation to be the .NET standard for Olson TZ information. I did not even know that any implementations were blessed as such. I had assumed that the main Olson tz information page was a reference page, and I was simply suggesting that adding a .NET reference would be incredibly valuable (since there is no such reference). I certainly wouldn't want mine to be the "standard" because I simply don't know if it is that up-to-par :-) Now, I think there is a very important discussion to be had about when a particular implementation is "stable" enough to be recommended. Take for example your situation in searching for a .NET olson timezone implementation: You had to search Google, newsgroups, MSDN, etc. I'm not sure what solution you came to, but I'm sure the first place you looked was http://www.twinsun.com/tz/tz-link.htm. You would have seen that the Olson time zone database is aware of a plethora of implementations, but none for .NET, and then would begin the complex search of finding functionality and knowing it works. I believe that this is a difficult hunt in the .NET world (at least when I did my full hunt before I created the package). It would be interesting if Olson had a suite of regression tests it could run on packages and bless them as valid implementations of the Olson time zone database. Perhaps it is a different section of the page or a link from the main page, but I think the current model of DIY or interpreting message group banter/trolling/lack of info is a hard one.

Other's have provided solutions, and though difficult to find, they are out there.

Just out of curiosity, what are some of the other .NET solutions?

Now, admittedly, I do prefer to insall classes that have pretty much a similar functions as opposed to those that incororate extra features.

Full time zone support in PublicDomain is available in 3 .cs files (which can be combined into one), and namespaces changed. Perhaps I could do this as a side project. The classes are there just not the packaging.

The whole business really becomse a non-trivial task to overcome in the Microsoft world, especially when developing for web applications that use MS SQL. It's really a challenge to provide web apps, when so many hosting providers cannot standardize on basic timezone settings. Of course, it's all part of relying on MS to bear the task to standardize on a better method. Just my thoughts, and wanted to clear up my last post, which was not meant to discourage, though I can see I was not clear. I apologize to you.

I completely agree. I used to worked at Microsoft and my informed guess is that they won't be switching any time soon because the demand is just not there. A large majority of Microsoft customers are siloed with ASP.NET/Windows/MS SQL/etc, and don't require interoperation. Until that changes, MS won't change their implementation... Thanks, Kevin