ZoneInfo vs. TZ4NET

Dec 6, 2011 at 5:30 PM


I'm comparing Olsen implementations for .Net and was wondering if anyone has done some analysis comparing this library vs. the "TZ4NET" library found on this page:  Here are my initial observations:

- Both are open sourced, but ZoneInfo is on CodePlex while TZ4NET is on a private web site.
- TZ4NET has had updates with each release of the Olsen tz data.  The latest is 2011n.
- ZoneInfo hasn't had updates since October 2008.
- Both TZ4NET and ZoneInfo have a single author.
- ZoneInfo has community contributions, but those patches have not been merged into the project.
- ZoneInfo works off of separate tzdata files that can be changed without recompiling, but doesn't work with the latest 2011n due to additions that aren't fully implemented in the code.
- TZ4NET has the binary tzdata embeded as resources into it's dll so the entire library has to be replaced with each tzdata release.
- ZoneInfo appears to have issues with daylight savings time transitions, as evidenced by the patch waiting release since April 2011.  Even with the patch applied, there appear to be issues in other time zones.  TZ4NET doesn't appear to have these issues.

So unless I'm missing something, I would be better off using TZ4NET - as long as the author keeps it maintained.  I'm still a bit hesitant in using it for production applications in the long term.

Is there some other solution for Olsen tzdata in .Net that may be more viable for a commercial product?

Dec 6, 2011 at 7:36 PM
mj1856 wrote:

- ZoneInfo appears to have issues with daylight savings time transitions, as evidenced by the patch waiting release since April 2011.  Even with the patch applied, there appear to be issues in other time zones.  TZ4NET doesn't appear to have these issues.

Which other issues might this be? We are using ZoneInfo in production and have no reports of issues.

Dec 6, 2011 at 8:56 PM

Well, I built a test project that pulls in both four separate implementations:

1) ZoneInfo with tzdata 2011n and patched with the 10855 patch to handle the new tokens.
2) ZoneInfo with tzdata 2011n, patched with 10855 AND 9207 for the DST fixes
3) TZ4NET with tzdata 2011n as is.
4) Microsoft TimeZoneInfo from .Net 4.0 with latest windows updates.  Using the CLDR conversion chart ( with a few minor updates.

I then loop through all time zones and loop again for all dates from 1/1/2011 through 1/1/2021 (I care more about future dates than past for my implementation).  I'm just comparing at midnight for ease of testing, which I understand could miss some items, but should still be fairly accurate.

I have performed all permutations of the four implementations through the same loops and every result is different, but they ALL fail.  I can certainly tell that any comparison to Microsoft's time zones are off probably due to Microsoft not keeping current.  Just focusing on the three tzdata implementations, they all use the same source data so they should all be identical except for bugs.  And if I am to belive that the 9207 patch for ZoneInfo is to fix all DST issues, then why do I get a large amount of mismatches when comparing against TZ4NET?   The list of timezones that fail the tests is long.

I am developing a product that will be sold worldwide and direcly involves timekeeping and crossing timezones.  We're storing all time in UTC, and displaying/reporting on it in the user's local timzone. So it's very important that we have a stable and accurate timezone conversion library so we show the correct information.



Dec 6, 2011 at 9:17 PM

Hi Matt,

This is very interesting for me because as I mentioned we already have ZoneInfo in production. Is there any reason in particular you feel TZ4NET is more accurate?

Are you in a position to share the tests you have written? I would be quite happy to go through the mismatches and work on fixes for ZoneInfo.


Dec 7, 2011 at 6:58 AM

Hi Matt,


I'm interested too about your test, because I have zoneinfo in production too. The "datasource" is the latest version foun in IANA (, the 2011n) withc works fine after a patch (10855) I publish, but without 9207 patch


Actually our SW is in used in europe, est europe, GB, US, brazil, south africa thailand, but it seems to be ok. It's not a scentific application, so I don't need a ultraaccurate conversion, for me the minute is ok. I don't see differences when I convert my datetime to others datetime zones. Could you post a sample?


Thanks in advice!



Dec 7, 2011 at 1:35 PM

Yes, I will post the test code.  Let me clean it up a bit more first.  I also want to compare some of the discrepancies manually against the 2011n tzdata so I can tell which implementation is correct.


Dec 7, 2011 at 7:48 PM

I uploaded the test solution to my skydrive:!158&parid=root

There are two implementations of ZoneInfo.  the "ZoneInfo1" is the current source tree, while the "ZoneInfo2" also includes patch 9207 that is yet uncommited.  In both implementations, I added the new Sun>=xx tokens to support the 2011n tzdata.

It appears that there are only discrepancies within the following 33 time zones:


However, note that I am only testing zones that have corresponding windows time zone info.  There may be others that are Olson only timezones that I did not compare.

Now the question is which of the implementations is most correct.  I will ponder over the results and see if I can tell.  Please let me know if you figure out anything also.


Mar 24, 2012 at 12:40 AM
Edited Mar 24, 2012 at 12:41 AM

Not sure if you all are interested but I've created a fork of this project on bit-bucket. Haven't implemented the patches yet but I have implemented the some things like loading zones from embedded resource in addition to the current method from files. I've also added some a lock for loading due to some issues I had when using this in a much-threaded application were i could not guarantee the database had been initialized.

Anyway sounds like I am not the only one using this thing these days and would be more than happy to add others so that the project is not maintained by a single person.

Apr 14, 2012 at 12:20 AM

I have migrated the zone and rules parsing to Regex to remove all the string manipulation. Need help testing the rest of the zone files but i think its quite a bit simpler to understand now. Also doing so has fixed some stuff that was getting kicked out by the old parsing so not sure if that will fix some issues others might have come across.

Apr 14, 2012 at 12:28 AM

I haven't done much with this in awhile, but I'm considering looking at yet-another implementation that comes with NodaTime.

NodaTime has its own Olsen timezone parser, but it comes with much much more.  Jon Skeet is leading it.  He has quite a following on StackOverflow and has written and published books on C#.  So although I haven't done the brute-force analysis yet, I have a bit more faith in his implementation.

Disclaimer: I've been contributing to NodaTime's JSON serialization support, but I haven't done anything with their tzinfo database yet.