Class DateTimeZone
Implements
Inherited Members
Namespace: NodaTime
Assembly: NodaTime.dll
Syntax
public abstract class DateTimeZone : IEquatable<DateTimeZone>, IZoneIntervalMap
Remarks
The mapping is unambiguous in the "UTC to local" direction, but the reverse is not true: when the offset changes, usually due to a Daylight Saving transition, the change either creates a gap (a period of local time which never occurs in the time zone) or an ambiguity (a period of local time which occurs twice in the time zone). Mapping back from local time to an instant requires consideration of how these problematic times will be handled.
Noda Time provides various options when mapping local time to a specific instant:
- AtStrictly(LocalDateTime) will throw an exception if the mapping from local time is either ambiguous or impossible, i.e. if there is anything other than one instant which maps to the given local time.
- AtLeniently(LocalDateTime) will never throw an exception due to ambiguous or skipped times, resolving to the later option of ambiguous matches or the start of the zone interval after the gap for skipped times.
- ResolveLocal(LocalDateTime, ZoneLocalMappingResolver) will apply a ZoneLocalMappingResolver to the result of a mapping.
- MapLocal(LocalDateTime) will return a ZoneLocalMapping with complete information about whether the given local time occurs zero times, once or twice. This is the most fine-grained approach, which is the fiddliest to use but puts the caller in the most control.
Noda Time has two built-in sources of time zone data available: a copy of the "zoneinfo" (aka tz or Olson) database, and the ability to convert .NET's own TimeZoneInfo format into a "native" Noda Time zone. Which of these is most appropriate for you to use will very much depend on your exact needs. The zoneinfo database is widely used outside Windows, and has more historical data than the Windows-provided information, but if you need to interoperate with other Windows systems by specifying time zone IDs, you may wish to stick to the Windows time zones.
To obtain a DateTimeZone for a given timezone ID, use one of the methods on IDateTimeZoneProvider (and see DateTimeZoneProviders for access to the built-in providers). The UTC timezone is also available via the Utc property on this class.
To obtain a DateTimeZone representing the system default time zone, you can either call
GetSystemDefault() on a provider to obtain the DateTimeZone that
the provider considers matches the system default time zone, or you can construct a
BclDateTimeZone
via BclDateTimeZone.ForSystemDefault
, which returns a
DateTimeZone that wraps the system local TimeZoneInfo. The latter will always
succeed, but has access only to that information available via the .NET time zone; the former may contain more
complete data, but may (in uncommon cases) fail to find a matching DateTimeZone.
Note that BclDateTimeZone
is not available on the PCL build of Noda Time, so this fallback strategy can
only be used with the desktop version.
Note that Noda Time does not require that DateTimeZone instances be singletons. As far as reasonably possible, implementations should implement IEquatable<T> in such a way that equivalent time zones compare as equal.
Constructors
DateTimeZone(String, Boolean, Offset, Offset)
Declaration
protected DateTimeZone(string id, bool isFixed, Offset minOffset, Offset maxOffset)
Parameters
Type | Name | Description |
---|---|---|
String | id | The unique id of this time zone. |
Boolean | isFixed | Set to true if this time zone has no transitions. |
Offset | minOffset | Minimum offset applied within this zone |
Offset | maxOffset | Maximum offset applied within this zone |
Remarks
The mapping is unambiguous in the "UTC to local" direction, but the reverse is not true: when the offset changes, usually due to a Daylight Saving transition, the change either creates a gap (a period of local time which never occurs in the time zone) or an ambiguity (a period of local time which occurs twice in the time zone). Mapping back from local time to an instant requires consideration of how these problematic times will be handled.
Noda Time provides various options when mapping local time to a specific instant:
- AtStrictly(LocalDateTime) will throw an exception if the mapping from local time is either ambiguous or impossible, i.e. if there is anything other than one instant which maps to the given local time.
- AtLeniently(LocalDateTime) will never throw an exception due to ambiguous or skipped times, resolving to the later option of ambiguous matches or the start of the zone interval after the gap for skipped times.
- ResolveLocal(LocalDateTime, ZoneLocalMappingResolver) will apply a ZoneLocalMappingResolver to the result of a mapping.
- MapLocal(LocalDateTime) will return a ZoneLocalMapping with complete information about whether the given local time occurs zero times, once or twice. This is the most fine-grained approach, which is the fiddliest to use but puts the caller in the most control.
Noda Time has two built-in sources of time zone data available: a copy of the "zoneinfo" (aka tz or Olson) database, and the ability to convert .NET's own TimeZoneInfo format into a "native" Noda Time zone. Which of these is most appropriate for you to use will very much depend on your exact needs. The zoneinfo database is widely used outside Windows, and has more historical data than the Windows-provided information, but if you need to interoperate with other Windows systems by specifying time zone IDs, you may wish to stick to the Windows time zones.
To obtain a DateTimeZone for a given timezone ID, use one of the methods on IDateTimeZoneProvider (and see DateTimeZoneProviders for access to the built-in providers). The UTC timezone is also available via the Utc property on this class.
To obtain a DateTimeZone representing the system default time zone, you can either call
GetSystemDefault() on a provider to obtain the DateTimeZone that
the provider considers matches the system default time zone, or you can construct a
BclDateTimeZone
via BclDateTimeZone.ForSystemDefault
, which returns a
DateTimeZone that wraps the system local TimeZoneInfo. The latter will always
succeed, but has access only to that information available via the .NET time zone; the former may contain more
complete data, but may (in uncommon cases) fail to find a matching DateTimeZone.
Note that BclDateTimeZone
is not available on the PCL build of Noda Time, so this fallback strategy can
only be used with the desktop version.
Note that Noda Time does not require that DateTimeZone instances be singletons. As far as reasonably possible, implementations should implement IEquatable<T> in such a way that equivalent time zones compare as equal.
Properties
Id
Declaration
public string Id { get; }
Property Value
Type | Description |
---|---|
String |
Remarks
This identifies the time zone within the current time zone provider; a different provider may provide a different time zone with the same ID, or may not provide a time zone with that ID at all.
MaxOffset
Declaration
public Offset MaxOffset { get; }
Property Value
Type | Description |
---|---|
Offset |
Remarks
The mapping is unambiguous in the "UTC to local" direction, but the reverse is not true: when the offset changes, usually due to a Daylight Saving transition, the change either creates a gap (a period of local time which never occurs in the time zone) or an ambiguity (a period of local time which occurs twice in the time zone). Mapping back from local time to an instant requires consideration of how these problematic times will be handled.
Noda Time provides various options when mapping local time to a specific instant:
- AtStrictly(LocalDateTime) will throw an exception if the mapping from local time is either ambiguous or impossible, i.e. if there is anything other than one instant which maps to the given local time.
- AtLeniently(LocalDateTime) will never throw an exception due to ambiguous or skipped times, resolving to the later option of ambiguous matches or the start of the zone interval after the gap for skipped times.
- ResolveLocal(LocalDateTime, ZoneLocalMappingResolver) will apply a ZoneLocalMappingResolver to the result of a mapping.
- MapLocal(LocalDateTime) will return a ZoneLocalMapping with complete information about whether the given local time occurs zero times, once or twice. This is the most fine-grained approach, which is the fiddliest to use but puts the caller in the most control.
Noda Time has two built-in sources of time zone data available: a copy of the "zoneinfo" (aka tz or Olson) database, and the ability to convert .NET's own TimeZoneInfo format into a "native" Noda Time zone. Which of these is most appropriate for you to use will very much depend on your exact needs. The zoneinfo database is widely used outside Windows, and has more historical data than the Windows-provided information, but if you need to interoperate with other Windows systems by specifying time zone IDs, you may wish to stick to the Windows time zones.
To obtain a DateTimeZone for a given timezone ID, use one of the methods on IDateTimeZoneProvider (and see DateTimeZoneProviders for access to the built-in providers). The UTC timezone is also available via the Utc property on this class.
To obtain a DateTimeZone representing the system default time zone, you can either call
GetSystemDefault() on a provider to obtain the DateTimeZone that
the provider considers matches the system default time zone, or you can construct a
BclDateTimeZone
via BclDateTimeZone.ForSystemDefault
, which returns a
DateTimeZone that wraps the system local TimeZoneInfo. The latter will always
succeed, but has access only to that information available via the .NET time zone; the former may contain more
complete data, but may (in uncommon cases) fail to find a matching DateTimeZone.
Note that BclDateTimeZone
is not available on the PCL build of Noda Time, so this fallback strategy can
only be used with the desktop version.
Note that Noda Time does not require that DateTimeZone instances be singletons. As far as reasonably possible, implementations should implement IEquatable<T> in such a way that equivalent time zones compare as equal.
MinOffset
Declaration
public Offset MinOffset { get; }
Property Value
Type | Description |
---|---|
Offset |
Remarks
The mapping is unambiguous in the "UTC to local" direction, but the reverse is not true: when the offset changes, usually due to a Daylight Saving transition, the change either creates a gap (a period of local time which never occurs in the time zone) or an ambiguity (a period of local time which occurs twice in the time zone). Mapping back from local time to an instant requires consideration of how these problematic times will be handled.
Noda Time provides various options when mapping local time to a specific instant:
- AtStrictly(LocalDateTime) will throw an exception if the mapping from local time is either ambiguous or impossible, i.e. if there is anything other than one instant which maps to the given local time.
- AtLeniently(LocalDateTime) will never throw an exception due to ambiguous or skipped times, resolving to the later option of ambiguous matches or the start of the zone interval after the gap for skipped times.
- ResolveLocal(LocalDateTime, ZoneLocalMappingResolver) will apply a ZoneLocalMappingResolver to the result of a mapping.
- MapLocal(LocalDateTime) will return a ZoneLocalMapping with complete information about whether the given local time occurs zero times, once or twice. This is the most fine-grained approach, which is the fiddliest to use but puts the caller in the most control.
Noda Time has two built-in sources of time zone data available: a copy of the "zoneinfo" (aka tz or Olson) database, and the ability to convert .NET's own TimeZoneInfo format into a "native" Noda Time zone. Which of these is most appropriate for you to use will very much depend on your exact needs. The zoneinfo database is widely used outside Windows, and has more historical data than the Windows-provided information, but if you need to interoperate with other Windows systems by specifying time zone IDs, you may wish to stick to the Windows time zones.
To obtain a DateTimeZone for a given timezone ID, use one of the methods on IDateTimeZoneProvider (and see DateTimeZoneProviders for access to the built-in providers). The UTC timezone is also available via the Utc property on this class.
To obtain a DateTimeZone representing the system default time zone, you can either call
GetSystemDefault() on a provider to obtain the DateTimeZone that
the provider considers matches the system default time zone, or you can construct a
BclDateTimeZone
via BclDateTimeZone.ForSystemDefault
, which returns a
DateTimeZone that wraps the system local TimeZoneInfo. The latter will always
succeed, but has access only to that information available via the .NET time zone; the former may contain more
complete data, but may (in uncommon cases) fail to find a matching DateTimeZone.
Note that BclDateTimeZone
is not available on the PCL build of Noda Time, so this fallback strategy can
only be used with the desktop version.
Note that Noda Time does not require that DateTimeZone instances be singletons. As far as reasonably possible, implementations should implement IEquatable<T> in such a way that equivalent time zones compare as equal.
Utc
DateTimeZoneProviders.Tzdb["UTC"]
.
Declaration
public static DateTimeZone Utc { get; }
Property Value
Type | Description |
---|---|
DateTimeZone | A UTC DateTimeZone. |
Remarks
The mapping is unambiguous in the "UTC to local" direction, but the reverse is not true: when the offset changes, usually due to a Daylight Saving transition, the change either creates a gap (a period of local time which never occurs in the time zone) or an ambiguity (a period of local time which occurs twice in the time zone). Mapping back from local time to an instant requires consideration of how these problematic times will be handled.
Noda Time provides various options when mapping local time to a specific instant:
- AtStrictly(LocalDateTime) will throw an exception if the mapping from local time is either ambiguous or impossible, i.e. if there is anything other than one instant which maps to the given local time.
- AtLeniently(LocalDateTime) will never throw an exception due to ambiguous or skipped times, resolving to the later option of ambiguous matches or the start of the zone interval after the gap for skipped times.
- ResolveLocal(LocalDateTime, ZoneLocalMappingResolver) will apply a ZoneLocalMappingResolver to the result of a mapping.
- MapLocal(LocalDateTime) will return a ZoneLocalMapping with complete information about whether the given local time occurs zero times, once or twice. This is the most fine-grained approach, which is the fiddliest to use but puts the caller in the most control.
Noda Time has two built-in sources of time zone data available: a copy of the "zoneinfo" (aka tz or Olson) database, and the ability to convert .NET's own TimeZoneInfo format into a "native" Noda Time zone. Which of these is most appropriate for you to use will very much depend on your exact needs. The zoneinfo database is widely used outside Windows, and has more historical data than the Windows-provided information, but if you need to interoperate with other Windows systems by specifying time zone IDs, you may wish to stick to the Windows time zones.
To obtain a DateTimeZone for a given timezone ID, use one of the methods on IDateTimeZoneProvider (and see DateTimeZoneProviders for access to the built-in providers). The UTC timezone is also available via the Utc property on this class.
To obtain a DateTimeZone representing the system default time zone, you can either call
GetSystemDefault() on a provider to obtain the DateTimeZone that
the provider considers matches the system default time zone, or you can construct a
BclDateTimeZone
via BclDateTimeZone.ForSystemDefault
, which returns a
DateTimeZone that wraps the system local TimeZoneInfo. The latter will always
succeed, but has access only to that information available via the .NET time zone; the former may contain more
complete data, but may (in uncommon cases) fail to find a matching DateTimeZone.
Note that BclDateTimeZone
is not available on the PCL build of Noda Time, so this fallback strategy can
only be used with the desktop version.
Note that Noda Time does not require that DateTimeZone instances be singletons. As far as reasonably possible, implementations should implement IEquatable<T> in such a way that equivalent time zones compare as equal.
Methods
AtLeniently(LocalDateTime)
Declaration
public ZonedDateTime AtLeniently(LocalDateTime localDateTime)
Parameters
Type | Name | Description |
---|---|---|
LocalDateTime | localDateTime | The local date/time to map. |
Returns
Type | Description |
---|---|
ZonedDateTime | The unambiguous mapping if there is one, the later result if the mapping is ambiguous, or the start of the later zone interval if the given local date/time is skipped. |
Remarks
AtStartOfDay(LocalDate)
Declaration
public ZonedDateTime AtStartOfDay(LocalDate date)
Parameters
Type | Name | Description |
---|---|---|
LocalDate | date | The local date to map in this time zone. |
Returns
Type | Description |
---|---|
ZonedDateTime | The ZonedDateTime representing the earliest time in the given date, in this time zone. |
Remarks
Exceptions
Type | Condition |
---|---|
SkippedTimeException | The entire day was skipped due to a very large time zone transition. (This is extremely rare.) |
AtStrictly(LocalDateTime)
Declaration
public ZonedDateTime AtStrictly(LocalDateTime localDateTime)
Parameters
Type | Name | Description |
---|---|---|
LocalDateTime | localDateTime | The local date and time to map into this time zone. |
Returns
Type | Description |
---|---|
ZonedDateTime | The unambiguous matching ZonedDateTime if it exists. |
Remarks
Exceptions
Type | Condition |
---|---|
SkippedTimeException | The given local date/time is skipped in this time zone. |
AmbiguousTimeException | The given local date/time is ambiguous in this time zone. |
Equals(DateTimeZone)
Declaration
public bool Equals(DateTimeZone obj)
Parameters
Type | Name | Description |
---|---|---|
DateTimeZone | obj | The DateTimeZone to compare with this instance. |
Returns
Type | Description |
---|---|
Boolean |
true if the specified DateTimeZone is equal to this instance;
otherwise, false .
|
Remarks
Equals(Object)
Declaration
public override sealed bool Equals(object obj)
Parameters
Type | Name | Description |
---|---|---|
Object | obj | The Object to compare with this instance. |
Returns
Type | Description |
---|---|
Boolean |
true if the specified Object is equal to this instance;
otherwise, false .
|
Overrides
Remarks
The mapping is unambiguous in the "UTC to local" direction, but the reverse is not true: when the offset changes, usually due to a Daylight Saving transition, the change either creates a gap (a period of local time which never occurs in the time zone) or an ambiguity (a period of local time which occurs twice in the time zone). Mapping back from local time to an instant requires consideration of how these problematic times will be handled.
Noda Time provides various options when mapping local time to a specific instant:
- AtStrictly(LocalDateTime) will throw an exception if the mapping from local time is either ambiguous or impossible, i.e. if there is anything other than one instant which maps to the given local time.
- AtLeniently(LocalDateTime) will never throw an exception due to ambiguous or skipped times, resolving to the later option of ambiguous matches or the start of the zone interval after the gap for skipped times.
- ResolveLocal(LocalDateTime, ZoneLocalMappingResolver) will apply a ZoneLocalMappingResolver to the result of a mapping.
- MapLocal(LocalDateTime) will return a ZoneLocalMapping with complete information about whether the given local time occurs zero times, once or twice. This is the most fine-grained approach, which is the fiddliest to use but puts the caller in the most control.
Noda Time has two built-in sources of time zone data available: a copy of the "zoneinfo" (aka tz or Olson) database, and the ability to convert .NET's own TimeZoneInfo format into a "native" Noda Time zone. Which of these is most appropriate for you to use will very much depend on your exact needs. The zoneinfo database is widely used outside Windows, and has more historical data than the Windows-provided information, but if you need to interoperate with other Windows systems by specifying time zone IDs, you may wish to stick to the Windows time zones.
To obtain a DateTimeZone for a given timezone ID, use one of the methods on IDateTimeZoneProvider (and see DateTimeZoneProviders for access to the built-in providers). The UTC timezone is also available via the Utc property on this class.
To obtain a DateTimeZone representing the system default time zone, you can either call
GetSystemDefault() on a provider to obtain the DateTimeZone that
the provider considers matches the system default time zone, or you can construct a
BclDateTimeZone
via BclDateTimeZone.ForSystemDefault
, which returns a
DateTimeZone that wraps the system local TimeZoneInfo. The latter will always
succeed, but has access only to that information available via the .NET time zone; the former may contain more
complete data, but may (in uncommon cases) fail to find a matching DateTimeZone.
Note that BclDateTimeZone
is not available on the PCL build of Noda Time, so this fallback strategy can
only be used with the desktop version.
Note that Noda Time does not require that DateTimeZone instances be singletons. As far as reasonably possible, implementations should implement IEquatable<T> in such a way that equivalent time zones compare as equal.
EqualsImpl(DateTimeZone)
Declaration
protected abstract bool EqualsImpl(DateTimeZone zone)
Parameters
Type | Name | Description |
---|---|---|
DateTimeZone | zone | The zone to compare with this one. This is guaranteed (when called by Equals(DateTimeZone)) to be a non-null reference of the same type as this instance. |
Returns
Type | Description |
---|---|
Boolean |
true if the specified DateTimeZone is equal to this instance;
otherwise, false .
|
Remarks
The mapping is unambiguous in the "UTC to local" direction, but the reverse is not true: when the offset changes, usually due to a Daylight Saving transition, the change either creates a gap (a period of local time which never occurs in the time zone) or an ambiguity (a period of local time which occurs twice in the time zone). Mapping back from local time to an instant requires consideration of how these problematic times will be handled.
Noda Time provides various options when mapping local time to a specific instant:
- AtStrictly(LocalDateTime) will throw an exception if the mapping from local time is either ambiguous or impossible, i.e. if there is anything other than one instant which maps to the given local time.
- AtLeniently(LocalDateTime) will never throw an exception due to ambiguous or skipped times, resolving to the later option of ambiguous matches or the start of the zone interval after the gap for skipped times.
- ResolveLocal(LocalDateTime, ZoneLocalMappingResolver) will apply a ZoneLocalMappingResolver to the result of a mapping.
- MapLocal(LocalDateTime) will return a ZoneLocalMapping with complete information about whether the given local time occurs zero times, once or twice. This is the most fine-grained approach, which is the fiddliest to use but puts the caller in the most control.
Noda Time has two built-in sources of time zone data available: a copy of the "zoneinfo" (aka tz or Olson) database, and the ability to convert .NET's own TimeZoneInfo format into a "native" Noda Time zone. Which of these is most appropriate for you to use will very much depend on your exact needs. The zoneinfo database is widely used outside Windows, and has more historical data than the Windows-provided information, but if you need to interoperate with other Windows systems by specifying time zone IDs, you may wish to stick to the Windows time zones.
To obtain a DateTimeZone for a given timezone ID, use one of the methods on IDateTimeZoneProvider (and see DateTimeZoneProviders for access to the built-in providers). The UTC timezone is also available via the Utc property on this class.
To obtain a DateTimeZone representing the system default time zone, you can either call
GetSystemDefault() on a provider to obtain the DateTimeZone that
the provider considers matches the system default time zone, or you can construct a
BclDateTimeZone
via BclDateTimeZone.ForSystemDefault
, which returns a
DateTimeZone that wraps the system local TimeZoneInfo. The latter will always
succeed, but has access only to that information available via the .NET time zone; the former may contain more
complete data, but may (in uncommon cases) fail to find a matching DateTimeZone.
Note that BclDateTimeZone
is not available on the PCL build of Noda Time, so this fallback strategy can
only be used with the desktop version.
Note that Noda Time does not require that DateTimeZone instances be singletons. As far as reasonably possible, implementations should implement IEquatable<T> in such a way that equivalent time zones compare as equal.
ForOffset(Offset)
Declaration
public static DateTimeZone ForOffset(Offset offset)
Parameters
Type | Name | Description |
---|---|---|
Offset | offset | The offset for the returned time zone |
Returns
Type | Description |
---|---|
DateTimeZone | A fixed time zone with the given offset. |
Remarks
The returned time zone will have an ID of "UTC" if the offset is zero, or "UTC+/-Offset" otherwise. In the former case, the returned instance will be equal to Utc.
Note also that this method is not required to return the same DateTimeZone instance for successive requests for the same offset; however, all instances returned for a given offset will compare as equal.
GetHashCode()
Declaration
public abstract override int GetHashCode()
Returns
Type | Description |
---|---|
Int32 | A hash code for this instance, suitable for use in hashing algorithms and data structures like a hash table. |
Overrides
Remarks
The mapping is unambiguous in the "UTC to local" direction, but the reverse is not true: when the offset changes, usually due to a Daylight Saving transition, the change either creates a gap (a period of local time which never occurs in the time zone) or an ambiguity (a period of local time which occurs twice in the time zone). Mapping back from local time to an instant requires consideration of how these problematic times will be handled.
Noda Time provides various options when mapping local time to a specific instant:
- AtStrictly(LocalDateTime) will throw an exception if the mapping from local time is either ambiguous or impossible, i.e. if there is anything other than one instant which maps to the given local time.
- AtLeniently(LocalDateTime) will never throw an exception due to ambiguous or skipped times, resolving to the later option of ambiguous matches or the start of the zone interval after the gap for skipped times.
- ResolveLocal(LocalDateTime, ZoneLocalMappingResolver) will apply a ZoneLocalMappingResolver to the result of a mapping.
- MapLocal(LocalDateTime) will return a ZoneLocalMapping with complete information about whether the given local time occurs zero times, once or twice. This is the most fine-grained approach, which is the fiddliest to use but puts the caller in the most control.
Noda Time has two built-in sources of time zone data available: a copy of the "zoneinfo" (aka tz or Olson) database, and the ability to convert .NET's own TimeZoneInfo format into a "native" Noda Time zone. Which of these is most appropriate for you to use will very much depend on your exact needs. The zoneinfo database is widely used outside Windows, and has more historical data than the Windows-provided information, but if you need to interoperate with other Windows systems by specifying time zone IDs, you may wish to stick to the Windows time zones.
To obtain a DateTimeZone for a given timezone ID, use one of the methods on IDateTimeZoneProvider (and see DateTimeZoneProviders for access to the built-in providers). The UTC timezone is also available via the Utc property on this class.
To obtain a DateTimeZone representing the system default time zone, you can either call
GetSystemDefault() on a provider to obtain the DateTimeZone that
the provider considers matches the system default time zone, or you can construct a
BclDateTimeZone
via BclDateTimeZone.ForSystemDefault
, which returns a
DateTimeZone that wraps the system local TimeZoneInfo. The latter will always
succeed, but has access only to that information available via the .NET time zone; the former may contain more
complete data, but may (in uncommon cases) fail to find a matching DateTimeZone.
Note that BclDateTimeZone
is not available on the PCL build of Noda Time, so this fallback strategy can
only be used with the desktop version.
Note that Noda Time does not require that DateTimeZone instances be singletons. As far as reasonably possible, implementations should implement IEquatable<T> in such a way that equivalent time zones compare as equal.
GetUtcOffset(Instant)
Declaration
public virtual Offset GetUtcOffset(Instant instant)
Parameters
Type | Name | Description |
---|---|---|
Instant | instant | The instant for which to calculate the offset. |
Returns
Type | Description |
---|---|
Offset | The offset from UTC at the specified instant. |
Remarks
GetZoneInterval(instant).WallOffset
,
although it can also be overridden for more efficiency.
GetZoneInterval(Instant)
Declaration
public abstract ZoneInterval GetZoneInterval(Instant instant)
Parameters
Type | Name | Description |
---|---|---|
Instant | instant | The Instant to query. |
Returns
Type | Description |
---|---|
ZoneInterval | The defined ZoneInterval. |
Remarks
See Also
GetZoneIntervals(Instant, Instant)
start
, end
).
Declaration
public IEnumerable<ZoneInterval> GetZoneIntervals(Instant start, Instant end)
Parameters
Type | Name | Description |
---|---|---|
Instant | start | Inclusive start point of the interval for which to retrieve zone intervals. |
Instant | end | Exclusive end point of the interval for which to retrieve zone intervals. |
Returns
Type | Description |
---|---|
IEnumerable<ZoneInterval> | A sequence of zone intervals covering the given interval. |
Remarks
This method is simply a convenience method for calling GetZoneIntervals(Interval) without explicitly constructing the interval beforehand.
Exceptions
Type | Condition |
---|---|
ArgumentOutOfRangeException | end is earlier than start |
See Also
GetZoneIntervals(Interval)
Declaration
public IEnumerable<ZoneInterval> GetZoneIntervals(Interval interval)
Parameters
Type | Name | Description |
---|---|---|
Interval | interval | Interval to find zone intervals for. |
Returns
Type | Description |
---|---|
IEnumerable<ZoneInterval> | A sequence of zone intervals covering the given interval. |
Remarks
The zone intervals are returned in chronological order. This method is equivalent to calling GetZoneInterval(Instant) for every instant in the interval and then collapsing to a set of distinct zone intervals. The first and last zone intervals are likely to also cover instants outside the given interval; the zone intervals returned are not truncated to match the start and end points.
See Also
MapLocal(LocalDateTime)
Declaration
public ZoneLocalMapping MapLocal(LocalDateTime localDateTime)
Parameters
Type | Name | Description |
---|---|---|
LocalDateTime | localDateTime | The local date and time to map in this time zone. |
Returns
Type | Description |
---|---|
ZoneLocalMapping | A mapping of the given local date and time to zero, one or two zoned date/time values. |
Remarks
ResolveLocal(LocalDateTime, ZoneLocalMappingResolver)
Declaration
public ZonedDateTime ResolveLocal(LocalDateTime localDateTime, ZoneLocalMappingResolver resolver)
Parameters
Type | Name | Description |
---|---|---|
LocalDateTime | localDateTime | |
ZoneLocalMappingResolver | resolver | The resolver to apply to the mapping. |
Returns
Type | Description |
---|---|
ZonedDateTime | The result of resolving the mapping. |
Remarks
This is a convenience method for calling MapLocal(LocalDateTime) and passing the result to the resolver. Common options for resolvers are provided in the static Resolvers class.
See AtStrictly(LocalDateTime) and AtLeniently(LocalDateTime) for alternative ways to map a local time to a specific instant.
Exceptions
Type | Condition |
---|---|
ArgumentNullException | resolver is null |
ToString()
Declaration
public override string ToString()
Returns
Type | Description |
---|---|
String | The ID of this time zone. |
Overrides
Remarks
The mapping is unambiguous in the "UTC to local" direction, but the reverse is not true: when the offset changes, usually due to a Daylight Saving transition, the change either creates a gap (a period of local time which never occurs in the time zone) or an ambiguity (a period of local time which occurs twice in the time zone). Mapping back from local time to an instant requires consideration of how these problematic times will be handled.
Noda Time provides various options when mapping local time to a specific instant:
- AtStrictly(LocalDateTime) will throw an exception if the mapping from local time is either ambiguous or impossible, i.e. if there is anything other than one instant which maps to the given local time.
- AtLeniently(LocalDateTime) will never throw an exception due to ambiguous or skipped times, resolving to the later option of ambiguous matches or the start of the zone interval after the gap for skipped times.
- ResolveLocal(LocalDateTime, ZoneLocalMappingResolver) will apply a ZoneLocalMappingResolver to the result of a mapping.
- MapLocal(LocalDateTime) will return a ZoneLocalMapping with complete information about whether the given local time occurs zero times, once or twice. This is the most fine-grained approach, which is the fiddliest to use but puts the caller in the most control.
Noda Time has two built-in sources of time zone data available: a copy of the "zoneinfo" (aka tz or Olson) database, and the ability to convert .NET's own TimeZoneInfo format into a "native" Noda Time zone. Which of these is most appropriate for you to use will very much depend on your exact needs. The zoneinfo database is widely used outside Windows, and has more historical data than the Windows-provided information, but if you need to interoperate with other Windows systems by specifying time zone IDs, you may wish to stick to the Windows time zones.
To obtain a DateTimeZone for a given timezone ID, use one of the methods on IDateTimeZoneProvider (and see DateTimeZoneProviders for access to the built-in providers). The UTC timezone is also available via the Utc property on this class.
To obtain a DateTimeZone representing the system default time zone, you can either call
GetSystemDefault() on a provider to obtain the DateTimeZone that
the provider considers matches the system default time zone, or you can construct a
BclDateTimeZone
via BclDateTimeZone.ForSystemDefault
, which returns a
DateTimeZone that wraps the system local TimeZoneInfo. The latter will always
succeed, but has access only to that information available via the .NET time zone; the former may contain more
complete data, but may (in uncommon cases) fail to find a matching DateTimeZone.
Note that BclDateTimeZone
is not available on the PCL build of Noda Time, so this fallback strategy can
only be used with the desktop version.
Note that Noda Time does not require that DateTimeZone instances be singletons. As far as reasonably possible, implementations should implement IEquatable<T> in such a way that equivalent time zones compare as equal.