User-visible changes from 1.0.0-beta1 onwards. See the project repository for more details.
See the end of this page for the policy on which versions receive patch updates for TZDB releases.
Changes since 3.1.x:
This patch release simply updates the built-in TZDB time zone data to 2024b, using CLDR version 44 for Windows mappings. (It also makes some trivial changes to documentation, but no actual code changes.)
This patch release simply updates the built-in TZDB time zone data to 2024a, using CLDR version 44 for Windows mappings.
This patch release simply updates the built-in TZDB time zone data to 2023d, using CLDR version 42 for Windows mappings.
This patch release simply updates the built-in TZDB time zone data to 2023c, using CLDR version 42 for Windows mappings.
This patch release simply updates the built-in TZDB time zone data to 2023b, using CLDR version 42 for Windows mappings.
This patch release simply updates the built-in TZDB time zone data to 2023a, using CLDR version 42 for Windows mappings.
This patch release simply updates the built-in TZDB time zone data to 2022g, using CLDR version 41 for Windows mappings.
This patch release simply updates the built-in TZDB time zone data to 2022f, using CLDR version 41 for Windows mappings.
This patch release simply updates the built-in TZDB time zone data to 2022e, using CLDR version 41 for Windows mappings.
This patch release simply updates the built-in TZDB time zone data to 2022d, using CLDR version 41 for Windows mappings.
This patch release simply updates the built-in TZDB time zone data to 2022c, using CLDR version 41 for Windows mappings.
There are no data differences between tzdb 2022b and 2022c; this release is primarily to avoid confusion as to why 2022c might be missing.
This patch release simply updates the built-in TZDB time zone data to 2022b, using CLDR version 40 for Windows mappings. (Note that CLDR 41 has been released, but has the same mappings as CLDR 40.)
Changes since 3.0.0:
DateOnly and TimeOnly conversions to/from
LocalDate and LocalTimeBclDateTimeZone support in .NET 6.0 on UnixToString method for YearMonthLocalDateTime.MinIsoValue and LocalDate.MaxIsoValuePeriod.Between overload accepting YearMonth valuesYearMonth.PlusMonths methodPeriod.DaysBetween method (previously internal)This set of patch releases simply updates the built-in TZDB time zone data to 2022a, using CLDR version 40 for Windows mappings.
This set of patch releases simply updates the built-in TZDB time zone data to 2021e, using CLDR version 39 for Windows mappings.
This set of patch releases simply updates the built-in TZDB time zone data to 2021d, using CLDR version 39 for Windows mappings.
This set of patch releases simply updates the built-in TZDB time zone data to 2021c, using CLDR version 38.1 for Windows mappings.
This set of patch releases simply updates the built-in TZDB time zone data to 2021b, using CLDR version 38.1 for Windows mappings.
This set of patch releases simply updates the built-in TZDB time zone data to 2021a, using CLDR version 38.1 for Windows mappings.
This set of patch releases simply updates the built-in TZDB time zone data to 2020e.
This set of patch releases simply updates the built-in TZDB time zone data to 2020d.
This set of patch releases simply updates the built-in TZDB time zone data to 2020c.
This set of patch releases simply updates the built-in TZDB time zone data to 2020b.
Changes since 2.x:
AnnualDate now implements the non-generic IComparable interfaceLocalTimePattern.GeneralIso property ("HH:mm:ss")LocalDate YearMonth.OnDayOfMonth(int)LocalDate, meaning "month/day pattern"ZonedDateTime. This uses the DateTimeZoneProvider
in NodaTime.Text.TypeConverterSettings for parsing.AnnualDateBclDateTimeZone now interprets a TimeZoneInfo rule of a transition at 23:59:59.999 as "at midnight" issue 1524Period issue 1529YearMonthYearMonth issue 1539LocalDate and YearMonthKnown issues:
New features since 3.0.0-beta02:
BclDateTimeZone now interprets a TimeZoneInfo rule of a transition at 23:59:59.999 as "at midnight" issue 1524Period issue 1529YearMonthYearMonth issue 1539LocalDate and YearMonthHopefully the last release before 3.0.0.
New features since 3.0.0-beta01:
AnnualDate now implements the non-generic IComparable interfaceLocalTimePattern.GeneralIso property ("HH:mm:ss")LocalDate YearMonth.OnDayOfMonth(int)LocalDate, meaning "month/day pattern"ZonedDateTime. This uses the DateTimeZoneProvider
in NodaTime.Text.TypeConverterSettings for parsing.AnnualDateSemi-breaking change:
DateTimeZoneProviders.Serialization is now deprecated. Use NodaTime.Xml.XmlSerializationSettings.DateTimeZoneProvider
instead. We'll keep DateTimeZoneProviders.Serialization in 3.0.0 for binary compatibility, but probably remove it for 4.0.0 (if
that ever happens). The deprecated property just delegates to the new property.This patch release simply updates the built-in TZDB time zone data to 2020a.
This patch release simply updates the built-in TZDB time zone data to 2019c.
First beta release of 3.0.0.
New features since 3.0.0-alpha01:
This patch release simply updates the built-in TZDB time zone data to 2019b.
This patch release simply updates the built-in TZDB time zone data to 2019a.
Initial alpha release to allow users to experiment with:
This patch release simply updates the built-in TZDB time zone data to 2018i.
This patch release mostly updates the built-in TZDB time zone data to 2018h. However, it also fixes issue 1227.
Note that the 2.3.x series no longer receives TZDB updates. The 1.4.x series has not been included in this update, but may be updated later. (See issue 1243 for discussion.)
This set of patch releases simply updates the built-in TZDB time zone data to 2018g.
This set of patch releases simply updates the built-in TZDB time zone data to 2018f.
New features:
Deconstruct methods to support C# 7 deconstruction in many typesMin/Max methods added to LocalDate, LocalTime and LocalDateTimeOffsetDate and OffsetTime structs added to represent dates or times-of-day with offsets,
with conversions from other types as appropriate.OffsetDateTime.InZone method added for easier conversion to ZonedDateTimeDateInterval: Contains(DateInterval), Union,
Intersection and iteration (it implements IEnumerable<LocalDate>)AnnualDate2.3.0-beta01 was released on 2017-12-13, and 2.3.0-beta02 was released on 2018-03-25.
This set of patch releases simply updates the built-in TZDB time zone data to 2018e. Note that this is the first release using negative DST. For example, Ireland observes standard time in the summer, and DST of -1 hour in the winter. This does not change any local times, just the standard/savings components.
This set of patch releases simply updates the built-in TZDB time zone data to 2018d.
This set of patch releases simply updates the built-in TZDB time zone data to 2018c. Note that 2018a and 2018b were skipped. 2018a and 2018b used negative daylight savings for Ireland in winter - a change that is under significant discussion, and is reverted in 2018c.
This set of patch releases simply rebuilds the previous set of releases, but in release mode instead of debug.
Fixes issue 1027.
This set of patch releases simply updates the built-in TZDB time zone data to 2017c.
Bug-fix release:
Instant bounds checking bypassed when subtracting a DurationBug-fix release:
This was an accidental release, immediately delisted on nuget.org but later relisted due to issues with it actually being visible anyway. (The NodaTime.Testing package was only released on July 14th.)
It's exactly the same as 2.1.0: upgrading from 2.1.0 to 2.2.0 should be a no-op.
Period which didn't get into 2.0.x (most Duration ones did)ToDayOfWeek extension method (issue 776)ParseResult to make it easier
to work with it in a functional context (issue 780)LocalDate.MinIsoValue/MaxIsoValue (issue 898)(Beta 1 was released on 2017-07-05. Only change since beta 1 was the final addition listed above.)
Release to enable migration to 2.0.
ZonedClock and WeekYearRules backported from 2.0IClock and IDateTimeZoneSource to allow smoother migrationCentury properties)IsoDayOfWeek properties which have been renamed to DayOfWeek in 2.0 have not been
made obsolete as there'd be no good way of dealing with this. (Just rename uses after migrating to 2.0.)(Beta 1 was released on 2017-07-04. No changes from beta to GA.)
Patch release: optimization only:
Instant.FromUnixTimeSeconds slow (fix in Duration.FromXyz)Duration performance furtherPatch release: bugfix only:
Patch release: bugfixes only:
LocalDate constructor validationLocalTime validationMajor release: do not expect to be able to upgrade from 1.x without making adjustments to your code; please read the list of breaking changes and see the Noda Time 1.x to 2.0 migration guide for full details.
New features include:
netstandard1.3 and net45 TFMsLocalDate-related operations due to new internal representationNodaTime.Extensions namespacevar monthEnd = date.With(DateAdjusters.EndOfMonth)19.June(1976)) in the NodaTime.Testing.Extensions namespaceAnnualDate to represent events like birthdays and anniversariesDateInterval - a LocalDate-based interval typeZonedClock - a wrapper around IClock with a time zone, making it easier to get the current day/time in a time zone repeatedlyWeekYearRules - a calendar-neutral way of extracting week-year informationCalendarSystemZonedDateTime and OffsetDateTime patternsBreaking changes:
IFormatProvider, only CultureInfo and DateTimeFormatInfo values can be used;
any other non-null reference will now throw an exception. When a DateTimeFormatInfo is provided,
the invariant culture is used for resource lookups and text comparisons.LocalDateTime constructors accepting tick valuesLocalTime constructors accepting tick values (tick-of-second and tick-of-millisecond)
to be static factory methods.Pattern suffixIsoDayOfWeek properties in LocalDate, LocalDateTime, OffsetDateTime
and ZonedDateTime to just DayOfWeek, and removed the previous numeric DayOfWeek properties.Instant(long) constructor from the public API.LocalTime.LocalDateTime property.LenientResolver to more closely match real-world usage.
This also affects DateTimeZone.AtLeniently and LocalDateTime.InZoneLeniently.
Period and PeriodBuilder properties for date-based values (years, months, weeks, days) are now of type int rather than long.LocalDate etc) now return 0001-01-01
instead of the Unix epoch.CalendarSystem.GetMaxMonth has been renamed to GetMonthsInYear.Offset can no longer represent sub-second offsets (which are not used in
practice); formatting and parsing for these has been removed.Offset now has a range of +/- 18 hours instead of just less than a complete day.Instant and Offset have been removed.IClock.Now to IClock.GetCurrentInstant().CenturyOfEra and YearOfCentury removed from LocalDate and related types.Duration.FromStandardDays has been renamed to Duration.FromDaysDuration.FromStandardWeeks has been removed.NodaConstants which had Standard in their name have had that part removed.y and yyy are no longer supported in date format specifiers; use yy or yyyy instead.yy and yyyy now refer to the year of era instead of the absolute year; u is used for absolute year.Instant have been renamed to FromUnixTimeXyz()Instant.Ticks property has been converted to a method, Instant.ToUnixTimeTicks(). (This reflects
the fact that it would no longer reflect the complete state of the object, and aims to obscure the fact
that the Unix epoch is the internal epoch in Noda Time.)NumberFormatInfo from a culture for positive or negative signs.WeekOfWeekYear) have been removed, in favour of a more
flexible system. See the week-years guide for more information.IDateTimeZoneSource.MapTimeZoneId and the introduction of IDateTimeZoneSource.GetSystemDefaultId instead.Bug fixes:
BclDateTimeZone has been reimplemented from scratch. This may result in a very few differences
in the interpretation of when an adjustment rule starts and ends. It is now known to be incompatible
with the BCL in well-understood ways which we don't intend to change.Other:
ReturnForwardShifted resolver, which shifts values in the daylight saving time "gap" forward by the duration of the gap,
effectively returning the instant that would have occurred had the gap not existed. This was added to support the new behaviour of
the "lenient" resolver (see above), but can also be used separately.IDateTimeZoneSource advertises a zone with an ID corresponding to a fixed-offset
zone, DateTimeZoneCache now consults the source first. This fixes issue 332.(No code changes.)
(No code changes.)
Only one code change, primarily an update to TZDB 2016c.
Bug fixes:
Bug fixes:
TimeZoneInfo API that caused
BclDateTimeZone to incorrectly calculate time zone conversions for
Russian time zones before 2014-10-26 (issue 342). (This is essentially
the same problem documented in Microsoft KB
3012229.)BclDateTimeZone are now considered equal if they wrap the
same underlying TimeZoneInfo, rather than always throwing
NotImplementedException (issue 334)NodaTime assembly now correctly declares a dependency on
System.Xml, required due to XML serialization support (issue 339)Other:
kpm restore (issue 345)TzdbCompiler to handle newer versions of the TZDB source
distributionMajor features:
API changes:
CalendarSystem.GetPersianCalendar() and Era.AnnoPersico for the
Persian calendarCalendarSystem.GetHebrewCalendar(), Era.AnnoMundi, and the
HebrewMonthNumbering enum for the Hebrew calendarLocalDate.At(LocalTime) and LocalTime.On(LocalDate), more
discoverable versions of LocalDate + LocalTime (issue 192)OffsetDateTime.WithOffset(), which returns an OffsetDateTime
representing the same point in time, but using a given offset (issue 246)ZonedDateTime.IsDaylightSavingTime(), mirroring the method of the
same name in System.DateTime (issue 264)OffsetDateTimePattern.CreateWithInvariantCulture(),
OffsetDateTimePattern.CreateWithCurrentCulture(), and
ZonedDateTimePattern.CreateWithCurrentCulture() (issue 267)OffsetDateTimePattern.Rfc3339Pattern, an RFC 3339-compliant pattern
formatter (issue 284)ZonedDateTimePattern patterns containing the G and F standard patterns
can now be used for parsing when used with a zone provider (issue 277)AllowPartiallyTrustedCallers
attribute (and relevant types with the SecurityCritical attribute),
allowing it to be used in partially-trusted contexts (issues issue 268
and issue 272)Interval.ToString() to
ISO-8601 interval format (issue 270)API changes for NodaTime.Serialization.JsonNet:
JsonSerializerSettings.WithIsoIntervalConverter() and
JsonSerializer.WithIsoIntervalConverter() extension methods, which change
the representation of a serialized Interval from the object-based format
(with 'Start' and 'End' properties) to the string representation using the
ISO-8601 interval format (issue 270)NodaConverters.IsoIntervalConverter, which provides access to the
JsonConverter used for the ISO-8601 interval formatBug fixes:
OffsetDateTime to emit
offsets compatible with RFC 3339, and by extension, with JavaScript's
Date.parse() and .NET's XML conversions (issue 284)Other:
Essentially identical to 1.3.0. The only change was the removal of some older TZDB versions from the source distribution.
Major features:
NodaTime.Serialization.JsonNet NuGet package enabling JSON
serialization for Noda Time types using Json.NETDuration, OffsetDateTime, and
ZonedDateTime, including new custom format patterns representing an
embedded offset (o), time zone identifier (z), (format-only) time zone
abbreviation (x), and various patterns for Duration (issues
issue 139, issue 171, and issue 216)API changes:
DateTimeZoneProviders.Serialization, which is a static mutable
property used to control the time zone provider used by XML and binary
serializationDurationPattern, OffsetDateTimePattern, and
ZonedDateTimePattern that represent patterns for parsing and formatting
Duration, OffsetDateTime, and ZonedDateTime respectivelyLocalDateTimePattern properties GeneralIsoPattern,
BclRoundtripPattern, and FullRoundtripPattern, which provide
programmatic access to the o/O, r, and s patterns, respectivelyToString()) for Duration, OffsetDateTime,
and ZonedDateTime has changedyyyy (for example, the standard ones)
can now parse and format five-digit years in cases where the result would
not be ambiguousInstantPattern.WithMinMaxLabels(), which allows replacement of the
text used to format the minimum and maximum instants (the defaults for
which have also changed)Era.AnnoMartyrum, obsoleting the misnamed AnnoMartyrmInstant.WithOffset(), which parallels the equivalent method in
LocalDateTimeOffsetDateTime.WithCalendar(), which returns an OffsetDateTime
representing the same point in time, but using a given calendar systemInterval.Contains(), which returns whether an Interval contains
the given InstantZonedDateTime.Calendar, which returns the calendar system used by
a ZonedDateTimeZonedDateTime.GetZoneInterval(), a convenience method that returns
the ZoneInterval of the time zone used by a ZonedDateTime
(issue 211)ParseResult.Exception, which provides direct access to the
exception that would be thrown by GetValueOrThrow()DateTimeZoneNotFoundException and InvalidNodaDataException are now
sealed (as they should have been from the start)CalendarSystem is now also sealed (though it was previously an
abstract class with an internal constructor, so this should have no
practical effect)Newly-obsolete members:
Era.AnnoMartyrm, which was a typo for the newly-introduced AnnoMartyrumBug fixes:
Period.Between() could return a mixture of positive
and negative values when called with end-of-month and near-leap-year
values (issue 223 and issue 224)Period.Between() would incorrectly overflow when
creating a Period that exceeded long.MaxValue ticks (issue 229)Instant no longer trim whitespace from the result
(issue 227)Instant patterns n, g, and d (issue 228)Other:
NodaTime-{All,Core,Documentation,Tools}.sln (issue 214)ZoneInfoCompiler tool has been renamed to NodaTime.TzdbCompilerFirst release of the NodaTime.Serialization.JsonNet assembly.
Essentially identical to 1.2.0. The only differences between 1.2.0-rc2 and 1.2.0 were documentation and release process improvements.
Essentially identical to 1.2.0. The only differences between 1.2.0-rc1 and 1.2.0-rc2 were within the NodaTime.Serialization.JsonNet assembly (not included in 1.2.0-rc1, and so not documented here), and to some benchmarks and documentation.
Bug fixes:
BclDateTimeZoneSource.GetIds() would not
return the local time zone ID, which caused
DateTimeZoneProviders.Bcl.GetSystemDefault() to fail (issue 235)TzdbDateTimeZoneSource.MapTimeZoneId() that caused
DateTimeZoneProviders.Tzdb.GetSystemDefault() to fail when the system
culture was set to something other than English (issue 221). Under the
PCL, we can't get the ID of a TimeZoneInfo, so we were relying on the
StandardName property - but that (unexpectedly) varies by system locale.
The fix adds a fallback that attempts to determine which TZDB time zone best
fits the given TimeZoneInfo, by looking at transitions of all zones in the
current year.API changes:
OffsetDateTime.Comparer and ZonedDateTime.Comparer,
IComparer<T> implementations that compare values by either the local
date/time or the underlying instantTzdbDateTimeZoneSource.WindowsZones renamed to WindowsMappingZoneEqualityComparer converted to use factory methods rather than
multiple constructors; some options' names changedMajor features:
API changes:
DateTimeZone.GetZoneIntervals methods return a sequence of zone
intervals which cover a particular interval (issue 172)ZoneEqualityComparer class allows time zones to be compared for
equality with varying degrees of strictness, over a given intervalLocalDate, LocalTime, LocalDateTime, and ZonedDateTime now
implement the non-generic IComparable interface (explicitly, to
avoid accidental use)TzdbDateTimeZoneSource:
Aliases and CanonicalIdMap properties, which together provide
bidirectional mappings between a canonical TZDB ID and its aliases
(issue 32)WindowsMapping property (was WindowsZones in -rc1), which
exposes details of the CLDR mapping between TZDB and Windows time zone
IDs (issue 82)ZoneLocations property, which exposes the location data from
zone.tab and iso3166.tab (issue 194)TzdbVersion property, which returns the TZDB version string
(e.g. "2013a")TzdbDateTimeZoneSource:
Default property, which provides access to the underlying source
of TZDB data distributed with Noda Time (issue 144)FromStream(), which can be used to create a source using data in
the new format produced by ZoneInfoCompiler (later renamed to NodaTime.TzdbCompiler)Validate() method, which allows for optional validation of
source data (previously, this was performed on every load)LocalDateTime patterns can now parse times of the form 24:00:00,
indicating midnight of the following day (issue 153)Instant:
From(Ticks,Milliseconds,Seconds)SinceUnixEpoch (issue 142)LocalTime:
From(Ticks,Milliseconds,Seconds)SinceMidnight (issue 148)LocalDateTime.InUtc() and WithOffset(), convenience conversions
from LocalDateTime to a (UTC) ZonedDateTime or OffsetDateTime
(issue 142)Date and TimeOfDay properties to ZonedDateTime and
OffsetDateTime, which provide a LocalDate and LocalTime directly,
rather than needing to go via the LocalDateTime property (issue 186)Period.FromMilliseconds(), obsoleting the misnamed
FromMillseconds() (issue 149)DateTimeZoneNotFoundException, which is used in place of the
.NET TimeZoneNotFoundException (which does not exist in the PCL);
on desktop builds, the new type extends the latter for compatibilityInvalidNodaDataException, which is now used to consistently
report problems reading time zone data; this replaces (inconsistent) use
of the .NET InvalidDataException type, which is also not available in
the PCLNewly-obsolete members:
DateTimeZoneProviders.Default, which use should be replaced by
existing equivalent property DateTimeZoneProviders.TzdbPeriod.FromMillseconds(), which was a typo for the newly-introduced
Period.FromMilliseconds()TzdbDateTimeZoneSource constructors, which construct a source using
TZDB data in the older resource-based format; the newer format should be
provided to the new TzdbDateTimeZoneSource.FromStream() method instead
(or, for the embedded resources, the new TzdbDateTimeZoneSource.Default
property should be used directly)API changes for NodaTime.Testing:
FakeDateTimeZoneSource, which is exactly what it sounds like
(issue 83)MultiTransitionDateTimeZone, a time zone with multiple
transitions, complementing the existing SingleTransitionDateTimeZoneSingleTransitionDateTimeZone.Transition property that returns
the transition point of the fake zoneSingleTransitionDateTimeZone
that allows the time zone ID to be specifiedBug fixes:
NodaIntervalConverter now handles values
embedded in a larger object being deserialized (issue 191)NullReferenceException when asked for a value in 2040
(and possibly other times). Other time zones should not be affected
(issue 174)LocalDateTime and ZonedDateTime now have non-crashing behaviour when
initialised via default (parameterless) constructors (issue 116)Other:
No API changes; this release was purely to fix a problem with the NodaTime.Testing package.
API changes:
CalendarSystem.Id property that returns a unique ID for a
calendar system, along with the ForId() factory method and Ids static
property; ToString() now returns the calendar ID rather than the namec custom format specifier for local date values,
which includes the calendar ID, representing the calendar system; custom format specifier to parse both comma
and period for fractions of a second; InstantPattern.ExtendedIsoPattern,
LocalTimePattern.ExtendedIsoPattern, and
LocalDateTimePattern.ExtendedIsoPattern now accept both as separators
(issue 140 and issue 141)r standard pattern for LocalDateTime that includes
the calendar systemCreateWithInvariantInfo() method on the pattern types to
CreateWithInvariantCulture() (issue 137)Other:
API changes:
DateTimeZone.GetOffsetFromUtc() to DateTimeZone.GetUtcOffset() to
match the BCL (issue 121)LocalDate.FromWeekYearWeekAndDay() (issue 120)Tick, SecondOfDay and MillisecondOfDay properties removed from
time-based types (issue 103)NodaCultureInfo and NodaFormatInfo types (issue 131 and
related issues), removed the FormatInfo property and WithFormatInfo()
method on pattern types, and changed the culture-specific pattern factory
methods to take a CultureInfo rather than a NodaFormatInfoEmptyDateTimeZoneSourcesealed: PeriodPattern, BclDateTimeZoneProvider,
BclDateTimeZoneSource, DateTimeZoneCache, and ZoneInterval, along
with various exception types and
NodaTime.Testing.SingleTransitionDateTimeZoneTzdbDateTimeZoneSource
(VersionKey, etc) are now internalBug fixes:
BclDateTimeZone not working the same way as a BCL
TimeZoneInfo (issue 114, issue 115, and issue 122)Other:
API changes:
Overhaul of how to get a DateTimeZone from an ID:
IDateTimeZoneProvider (SPI for time zones) renamed to
IDateTimeZoneSource, along with similar renaming for the built-in
sourcesIDateTimeZoneProvider aimed at callers, with caching
assumedDateTimeZoneProviders with static properties to access the
built-in providers: TZDB, BCL and default (currently TZDB)DateTimeZone static methods in favour of always going
via an IDateTimeZoneProvider implementationDateTimeZoneCache now public and implements IDateTimeZoneProviderDateTimeZone no longer has internal abstract methods, making third-party
implementations possible (issue 77)
DateTimeZone now implements IEquatable<DateTimeZone>, and documents what
it means for time zones to be equal (issue 81)
New core type: OffsetDateTime representing a local date/time and an offset
from UTC, but not full time zone information
Added a new standard offset pattern of G, which is like g but using
"Z" for zero; also available as OffsetPattern.GeneralInvariantPatternWithZ
Period and PeriodBuilder no longer differentiate between absent and zero
components (to the extent that they did at all): Units has been removed
from Period, period formatting now omits all zero values unconditionally,
and the Year (etc) properties on PeriodBuilder are no longer nullable
(issue 90)
Removed the BCL parsing methods and some of the BCL formatting methods from
Instant, LocalDate, LocalDateTime, and Offset in favour of the
pattern-based API (issue 87)
Duration.ToString() and Interval.ToString() now return more descriptive
text
Removed DateTimeZone.GetSystemDefaultOrNull(); callers should use the
provider's GetSystemDefault() method and (if necessary) catch the
TimeZoneNotFoundException that it can throw (issue 61)
Removed DateTimeZone.UtcId and DateTimeZone.IsFixed (issue 64
and issue 62)
Removed most of the convenience static properties on Duration (e.g.
Duration.OneStandardDay) in favour of the existing static methods; removed
MinValue and MaxValue, and added Epsilon (issue 70)
Removed Instant.BeginningOfTimeLabel and Instant.EndOfTimeLabel
Instant.InIsoUtc renamed to InUtc
Instant.UnixEpoch moved to NodaConstants.UnixEpoch;
NodaConstants.DateTimeEpochTicks replaced by BclEpoch
Added Instant.PlusTicks()
LocalDate.LocalDateTime property changed to LocalDate.AtMidnight() method
(issue 56)
LocalTime now implements IComparable<LocalTime> (issue 51)
Added a LocalTime constructor taking hours and minutes (issue 53)
Removed "component" properties from Offset, and renamed the "total"
properties to just Ticks and Milliseconds
Removed Offset.Create() methods (and moved them in slightly different form
in a new internal TestObjects class in NodaTime.Test)
Added Period.ToDuration() (issue 55) and Period.CreateComparer()
(issue 69)
Period.Empty renamed to Period.Zero (as part of issue 90)
PeriodBuilder no longer implements IEquatable<PeriodBuilder>
(issue 91)
Removed SystemClock.SystemNow in favour of using SystemClock.Instance.Now
if you really have to
Added ZonedDateTime.ToOffsetDateTime(), which returns the OffsetDateTime
equivalent to a ZonedDateTime
Removed the Buddhist Era (as there is no Buddhist calendar implementation)
NodaTime.Testing.StubClock renamed to FakeClock, and gains an
auto-advance option (issue 72 and issue 73)
NodaTime.Testing.TimeZones.SingleTransitionZone renamed to
SingleTransitionDateTimeZone
Bug fixes:
New time zone data is released by IANA as required. The latest data is always available via the Noda Time web site as described in the user guide. Additionally, NuGet packages are updated with a patch release to include the latest data.
The latest minor release for each supported major version is always updated. Additionally, if the latest minor release is less than 6 months old, the previous minor release is also updated. In other words, if you check once every 6 months to make sure you're on the latest minor release, you should always get patch releases containing TZDB updates.
The 1.x and 2.x series of Noda Time are no longer being updated to include new versions of TZDB. However, they are still compatible with the new NZD files: if you fetch the NZD file from the web site (as described in the user guide) you can use the latest time zone data with old versions of Noda Time.