It’s been a while since the last Noda Time release, and while we’re still working towards 2.0, we’ve been collecting a few bug fixes that can’t really wait. So last Friday1, we released Noda Time 1.3.1.
Noda Time 1.3.1 updates the built-in version of TZDB from 2014e to 2015a, and fixes a few minor bugs, two of which were triggered by recent data changes.
Since it’s been a while since the previous release, it may be worth pointing out that new Noda Time releases are not the only way to get new time zone data: applications can choose to load an external version of the time zone database rather than use the embedded version, and so use up-to-date time zone data with any version of the Noda Time assemblies.
If you’re in a hurry, you can get Noda Time 1.3.1 from the NuGet repository (core, testing, JSON support packages), or from the links on the Noda Time home page. The rest of this post talks about the changes in 1.3.1 in a bit more detail.
End of year transitions (Bangladesh)
In the middle of 2009, Bangladesh started observing permanent daylight saving time, as an energy-saving measure. This was abandoned at the end of that year, and the country went back to permanent standard time.
Until recently, that transition back to standard time was actually recorded as happening a minute too early, at 23:59 on December 31st. TZDB 2014g fixed this by changing the transition time to “24:00” — that is, midnight at the end of the last day of the year.
Noda Time could already handle transitions at the end of the day, but would incorrectly ignore this particular transition because it occurred ‘after’ 2009. That’s now fixed, and Noda Time 1.3.1 returns the correct offset for Asia/Dhaka when using data from TZDB 2014g or later.
BCL provider: historical changes to the base offset (Russia)
In October 2014, most of Russia switched from permanent daylight saving time to permanent standard time, effectively moving local time back one hour. These changes were included in TZDB 2014f.
For people using the BCL provider instead of the TZDB
provider (and using Windows), Microsoft delivered a
hotfix in September 2014. However, our BCL provider depends upon the .NET
TimeZoneInfo class, and the .NET framework — unlike TZDB —
is unable to represent historical changes to the ‘base’ offset of a time
zone (as happened here).
The result is that Noda Time (and other applications using
TimeZoneInfo in .NET 4.5.3 and earlier) incorrectly compute the offset for
dates before October 26th, 2014.
A future update of the .NET framework should correct this limitation, but
without a corresponding change in Noda Time, the extra information wouldn’t
be used; Noda Time 1.3.1 prepares for this change, and will use the correct
offset for historical dates when
BCL provider: time zone equality
The time zones returned by the BCL provider have long had a limitation in
the way time zone equality was implemented: a BCL time zone was considered
equal to itself, and unequal to a time zone returned by a different
provider, but attempting to compare two different BCL time zone instances
for equality always threw a
NotImplementedException. This was
particularly annoying for
ZonedDateTime, as its equality is defined in
terms of the contained
This was documented, but we always considered it a bug, as it wasn’t
possible to predict whether testing for equality would throw an exception.
Noda Time 1.3.1 fixes this by implementing equality in terms of the
TimeZoneInfo: BCL time zones are considered equal if they wrap
the same underlying
Note that innate time zone equality is not really well defined in general,
and is something we’re planning to reconsider for Noda Time 2.0. Rather
than rely on
DateTimeZone.Equals(), we’d recommend that applications that
want to compare time zones for equality use
ZoneEqualityComparer to specify how two time
zones should be compared.
There are a handful of other smaller fixes in 1.3.1: the
correctly declares a dependency on
System.Xml, so you won’t have to; the
NuGet packages now work with ASP.NET’s
kpm tool, and declare support for
Xamarin’s Xamarin.iOS (for building iOS applications using C#)
in addition to Xamarin.Android, which was already listed; and we’ve fixed a
few reported documentation issues along the way.
Work is still continuing on 2.0 along the lines described in our 1.3.0 release post, and we’re also planning a 1.4 release to act as a bridge between 1.x and 2.0. This will deprecate members that we plan to remove in 2.0 and introduce the replacements where feasible.
Release late on Friday afternoon? What could go wrong? Apart from running out of time to write a blog post, I mean. ↩