The NodaTime namespace contains the core types for Noda Time,
including the main public classes for time zone and calendar support
which have implementations (and less frequently used types) in other
namespaces. For formatting and parsing functionality, see the
The NodaTime.Calendars namespace contains types related to calendars beyond the
CalendarSystem type in the core NodaTime namespace.
The NodaTime.Extensions namespace contains extensions for all Noda Time production types
(regardless of their original namespace). Developers using C# 6 onwards are encouraged to import
specific types from within this namespace in order to only expose the extension methods
they're directly interested in; developers using earlier versions of C# will have to import
the whole namespace and ignore extension methods they are not interested in.
The NodaTime.Globalization namespace contains types related to culture-sensitive
aspects of behaviour, principally for the sake of text formatting and parsing.
The NodaTime.Text namespace contains types related to formatting and parsing date and time
values to and from text. Each core Noda Time type has its own "pattern" class to create a more
object-oriented (and efficient) approach to text handling than the one taken to the BCL.
See the user guide for more information.
The NodaTime.TimeZones namespace contains types related to time zones beyond the core
DateTimeZone class in the NodaTime namespace. Most users will have no need
to refer to the types in this namespace.
The NodaTime.TimeZones.Cldr namespace contains types related to time zone information provided
by the Unicode CLDR (Common Locale Data Repository) project.
The NodaTime.Utility namespace contains helper classes which don't really fit anywhere else.
The NodaTime.Testing namespace contains types designed to help write tests against
code which uses Noda Time. "Child" namespaces are organized to reflect the same structure
as the main project.
The NodaTime.Testing.Extensions namespace contains static classes
with extension methods to allow easier creation of test values.
The NodaTime.Testing.TimeZones namespace provides types to aid testing production
code which uses time zones, to avoid hard-coding knowledge of "real" time zones into tests.
The NodaTime.Serialization.JsonNet namespace contains support code to enable
JSON serialization for Noda Time types using Json.NET.
The NodaTime.Serialization.Protobuf namespace contains extension
methods to convert between NodaTime types and the
types exposed in Google.Protobuf
Exception thrown to indicate that the specified local date/time occurs twice
in a particular time zone due to daylight saving time changes.
A calendar system maps the non-calendar-specific "local time line" to human concepts
such as years, months and days.
Extension methods for IClock to enable migration to Noda Time 2.0.
Represents a time zone - a mapping between UTC and local time. A time zone maps UTC instants to local times
- or, equivalently, to the offset from UTC at any particular instant.
Static access to date/time zone providers built into Noda Time and for global configuration where this is unavoidable.
All properties are thread-safe, and the providers returned by the read-only properties cache their results.
Useful constants, mostly along the lines of "number of milliseconds in an hour".
Represents a period of time expressed in human chronological terms: hours, days,
weeks, months and so on.
A mutable builder class for Period values. Each property can
be set independently, and then a Period can be created from the result
using the Build() method.
Exception thrown to indicate that the specified local time doesn't
exist in a particular time zone due to daylight saving time changes.
Singleton implementation of IClock which reads the current system time.
It is recommended that for anything other than throwaway code, this is only referenced
in a single place in your code: where you provide a value to inject into the rest of
your application, which should only depend on the interface.
A clock with an associated time zone and calendar. This is effectively a convenience
class decorating an IClock.
Represents a fixed (and calendar-independent) length of time.
Represents an instant on the global timeline.
An interval between two instants in time (start and end).
LocalDate is an immutable struct representing a date within the calendar,
with no reference to a particular time zone or time of day.
A date and time in a particular calendar system. A LocalDateTime value does not represent an
instant on the time line, because it has no associated time zone: "November 12th 2009 7pm, ISO calendar"
occurred at different instants for different people around the world.
LocalTime is an immutable struct representing a time of day, with no reference
to a particular calendar, time zone or date.
An offset from UTC in milliseconds. A positive value means that the local time is
ahead of UTC (e.g. for Europe); a negative value means that the local time is behind
UTC (e.g. for America).
A local date and time in a particular calendar system, combined with an offset from UTC. This is
broadly similar to DateTimeOffset in the BCL.
A LocalDateTime in a specific time zone and with a particular offset to distinguish
between otherwise-ambiguous instants. A ZonedDateTime is global, in that it maps to a single
Represents a clock which can return the current time as an Instant.
Provides stable, performant time zone data.
Equates the days of the week with their numerical value according to
ISO-8601. This corresponds with System.DayOfWeek except for Sunday, which
is 7 in the ISO numbering and 0 in System.DayOfWeek.
The units within a Period. When a period is created to find the difference between two local values,
the caller may specify which units are required - for example, you can ask for the difference between two dates
in "years and weeks". Units are always applied largest-first in arithmetic.