C#/VB.NET PublicDomain Olson Time Zone Database Implementation

[Kevin]

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