TimeZoneInfo, if a timezone changes in the world, how quickly will microsoft roll out an update

I'm just wondering what happens in the case of a time zone changing, when your product is using .net开发者_如何转开发.

Is all you can do wait for Microsoft to update .net or write your own system for handling it?

I'm assuming this stuff doesn't happen very often, but is this an example of why a close system may not be a good idea?

Usually I'd expect Microsoft to roll out a Windows Update reasonably quickly - hopefully before the DST change itself. Most countries announce their intentions well ahead of time (like the US giving 2 years of notice) - but sometimes it can be less than a fortnight. (Argentina, I'm looking at you.)

I believe that TimeZoneInfo uses the information from Windows itself - so you'd be looking for a general Windows update rather than a .NET update.

But yes, I agree it would be nice to have a robust, fully-featured open source date/time library.

As it happens, I'm in the middle of helping to build one - do join in :)

When Noda Time is released, it will be easy to compile new time zone data yourself whenever you want - although of course I'd hope to release new time zone files in a timely fashion too.

MS will update Windows in the monthly releases, but sometimes it's not enough. If that happens you always can update the registry to update the timezone (it's documented on msdn). It's so much easier than builing your own framework.

First thing -- I wouldn't roll my own system here. Either wait for Windows or use an open source package.

I think it's pretty inflammatory to cite this as an example of closed-source v. open source.

It's an example of updating a section of a gigantic code base versus updating a very small one. It's an example of regression testing possibly thousands of dependencies versus regression testing the isolated library (it would be up to you to test your code against an open source library's changes).

It's also an example of importance. If your application requires that the time zone be correct, then it would be better to have an implementation you can modify than to be at the mercy of Microsoft (basically an interpretation of "don't outsource your core business").

You need to be careful when dealing with DST Transitions in System.TimeZoneInfo. Default AdjustmentRules are not necessarily comprehensive enough even for DST changes that have already occurred 30 years ago. More information in my response to another stackoverflow question : https://stackoverflow.com/a/15363375/1277069