Struct ZonedDateTime
Inherited Members
Namespace: NodaTime
Assembly: NodaTime.dll
Syntax
public struct ZonedDateTime : IEquatable<ZonedDateTime>, IComparable<ZonedDateTime>, IComparable
Remarks
Although ZonedDateTime includes both local and global concepts, it only supports duration-based - and not calendar-based - arithmetic. This avoids ambiguities and skipped date/time values becoming a problem within a series of calculations; instead, these can be considered just once, at the point of conversion to a ZonedDateTime.
Comparisons of values can be handled in a way which is either calendar and zone sensitive or insensitive. Noda Time implements all the operators (and the Equals(ZonedDateTime) method) such that all operators other than Inequality(ZonedDateTime, ZonedDateTime) will return false if asked to compare two values in different calendar systems or time zones.
However, the CompareTo(ZonedDateTime) method (implementing IComparable<T>) is calendar and zone insensitive; it compares the two global instants in terms of when they actually occurred.
It's unclear at the time of this writing whether this is the most appropriate approach, and it may change in future versions. In general, it would be a good idea for users to avoid comparing dates in different calendar systems, and indeed most users are unlikely to ever explicitly consider which calendar system they're working in anyway.
Currently there is no real text handling support for this type.
Constructors
ZonedDateTime(Instant, DateTimeZone)
Declaration
public ZonedDateTime(Instant instant, DateTimeZone zone)
Parameters
Type | Name | Description |
---|---|---|
Instant | instant | The instant. |
DateTimeZone | zone | The time zone. |
Remarks
Although ZonedDateTime includes both local and global concepts, it only supports duration-based - and not calendar-based - arithmetic. This avoids ambiguities and skipped date/time values becoming a problem within a series of calculations; instead, these can be considered just once, at the point of conversion to a ZonedDateTime.
Comparisons of values can be handled in a way which is either calendar and zone sensitive or insensitive. Noda Time implements all the operators (and the Equals(ZonedDateTime) method) such that all operators other than Inequality(ZonedDateTime, ZonedDateTime) will return false if asked to compare two values in different calendar systems or time zones.
However, the CompareTo(ZonedDateTime) method (implementing IComparable<T>) is calendar and zone insensitive; it compares the two global instants in terms of when they actually occurred.
It's unclear at the time of this writing whether this is the most appropriate approach, and it may change in future versions. In general, it would be a good idea for users to avoid comparing dates in different calendar systems, and indeed most users are unlikely to ever explicitly consider which calendar system they're working in anyway.
Currently there is no real text handling support for this type.
ZonedDateTime(Instant, DateTimeZone, CalendarSystem)
Declaration
public ZonedDateTime(Instant instant, DateTimeZone zone, CalendarSystem calendar)
Parameters
Type | Name | Description |
---|---|---|
Instant | instant | The instant. |
DateTimeZone | zone | The time zone. |
CalendarSystem | calendar | The calendar system. |
Remarks
Although ZonedDateTime includes both local and global concepts, it only supports duration-based - and not calendar-based - arithmetic. This avoids ambiguities and skipped date/time values becoming a problem within a series of calculations; instead, these can be considered just once, at the point of conversion to a ZonedDateTime.
Comparisons of values can be handled in a way which is either calendar and zone sensitive or insensitive. Noda Time implements all the operators (and the Equals(ZonedDateTime) method) such that all operators other than Inequality(ZonedDateTime, ZonedDateTime) will return false if asked to compare two values in different calendar systems or time zones.
However, the CompareTo(ZonedDateTime) method (implementing IComparable<T>) is calendar and zone insensitive; it compares the two global instants in terms of when they actually occurred.
It's unclear at the time of this writing whether this is the most appropriate approach, and it may change in future versions. In general, it would be a good idea for users to avoid comparing dates in different calendar systems, and indeed most users are unlikely to ever explicitly consider which calendar system they're working in anyway.
Currently there is no real text handling support for this type.
Exceptions
Type | Condition |
---|---|
ArgumentNullException | zone or calendar is null. |
ZonedDateTime(LocalDateTime, DateTimeZone, Offset)
Declaration
public ZonedDateTime(LocalDateTime localDateTime, DateTimeZone zone, Offset offset)
Parameters
Type | Name | Description |
---|---|---|
LocalDateTime | localDateTime | The local date and time. |
DateTimeZone | zone | The time zone. |
Offset | offset | The offset between UTC and local time at the desired instant. |
Remarks
Although ZonedDateTime includes both local and global concepts, it only supports duration-based - and not calendar-based - arithmetic. This avoids ambiguities and skipped date/time values becoming a problem within a series of calculations; instead, these can be considered just once, at the point of conversion to a ZonedDateTime.
Comparisons of values can be handled in a way which is either calendar and zone sensitive or insensitive. Noda Time implements all the operators (and the Equals(ZonedDateTime) method) such that all operators other than Inequality(ZonedDateTime, ZonedDateTime) will return false if asked to compare two values in different calendar systems or time zones.
However, the CompareTo(ZonedDateTime) method (implementing IComparable<T>) is calendar and zone insensitive; it compares the two global instants in terms of when they actually occurred.
It's unclear at the time of this writing whether this is the most appropriate approach, and it may change in future versions. In general, it would be a good idea for users to avoid comparing dates in different calendar systems, and indeed most users are unlikely to ever explicitly consider which calendar system they're working in anyway.
Currently there is no real text handling support for this type.
Exceptions
Type | Condition |
---|---|
ArgumentNullException | zone is null |
ArgumentException | offset is not a valid offset at the given
local date and time |
Properties
CenturyOfEra
Declaration
public int CenturyOfEra { get; }
Property Value
Type | Description |
---|---|
Int32 |
Remarks
Although ZonedDateTime includes both local and global concepts, it only supports duration-based - and not calendar-based - arithmetic. This avoids ambiguities and skipped date/time values becoming a problem within a series of calculations; instead, these can be considered just once, at the point of conversion to a ZonedDateTime.
Comparisons of values can be handled in a way which is either calendar and zone sensitive or insensitive. Noda Time implements all the operators (and the Equals(ZonedDateTime) method) such that all operators other than Inequality(ZonedDateTime, ZonedDateTime) will return false if asked to compare two values in different calendar systems or time zones.
However, the CompareTo(ZonedDateTime) method (implementing IComparable<T>) is calendar and zone insensitive; it compares the two global instants in terms of when they actually occurred.
It's unclear at the time of this writing whether this is the most appropriate approach, and it may change in future versions. In general, it would be a good idea for users to avoid comparing dates in different calendar systems, and indeed most users are unlikely to ever explicitly consider which calendar system they're working in anyway.
Currently there is no real text handling support for this type.
ClockHourOfHalfDay
Declaration
public int ClockHourOfHalfDay { get; }
Property Value
Type | Description |
---|---|
Int32 |
Remarks
Although ZonedDateTime includes both local and global concepts, it only supports duration-based - and not calendar-based - arithmetic. This avoids ambiguities and skipped date/time values becoming a problem within a series of calculations; instead, these can be considered just once, at the point of conversion to a ZonedDateTime.
Comparisons of values can be handled in a way which is either calendar and zone sensitive or insensitive. Noda Time implements all the operators (and the Equals(ZonedDateTime) method) such that all operators other than Inequality(ZonedDateTime, ZonedDateTime) will return false if asked to compare two values in different calendar systems or time zones.
However, the CompareTo(ZonedDateTime) method (implementing IComparable<T>) is calendar and zone insensitive; it compares the two global instants in terms of when they actually occurred.
It's unclear at the time of this writing whether this is the most appropriate approach, and it may change in future versions. In general, it would be a good idea for users to avoid comparing dates in different calendar systems, and indeed most users are unlikely to ever explicitly consider which calendar system they're working in anyway.
Currently there is no real text handling support for this type.
Date
Declaration
public LocalDate Date { get; }
Property Value
Type | Description |
---|---|
LocalDate |
Remarks
Although ZonedDateTime includes both local and global concepts, it only supports duration-based - and not calendar-based - arithmetic. This avoids ambiguities and skipped date/time values becoming a problem within a series of calculations; instead, these can be considered just once, at the point of conversion to a ZonedDateTime.
Comparisons of values can be handled in a way which is either calendar and zone sensitive or insensitive. Noda Time implements all the operators (and the Equals(ZonedDateTime) method) such that all operators other than Inequality(ZonedDateTime, ZonedDateTime) will return false if asked to compare two values in different calendar systems or time zones.
However, the CompareTo(ZonedDateTime) method (implementing IComparable<T>) is calendar and zone insensitive; it compares the two global instants in terms of when they actually occurred.
It's unclear at the time of this writing whether this is the most appropriate approach, and it may change in future versions. In general, it would be a good idea for users to avoid comparing dates in different calendar systems, and indeed most users are unlikely to ever explicitly consider which calendar system they're working in anyway.
Currently there is no real text handling support for this type.
Day
Declaration
public int Day { get; }
Property Value
Type | Description |
---|---|
Int32 |
Remarks
Although ZonedDateTime includes both local and global concepts, it only supports duration-based - and not calendar-based - arithmetic. This avoids ambiguities and skipped date/time values becoming a problem within a series of calculations; instead, these can be considered just once, at the point of conversion to a ZonedDateTime.
Comparisons of values can be handled in a way which is either calendar and zone sensitive or insensitive. Noda Time implements all the operators (and the Equals(ZonedDateTime) method) such that all operators other than Inequality(ZonedDateTime, ZonedDateTime) will return false if asked to compare two values in different calendar systems or time zones.
However, the CompareTo(ZonedDateTime) method (implementing IComparable<T>) is calendar and zone insensitive; it compares the two global instants in terms of when they actually occurred.
It's unclear at the time of this writing whether this is the most appropriate approach, and it may change in future versions. In general, it would be a good idea for users to avoid comparing dates in different calendar systems, and indeed most users are unlikely to ever explicitly consider which calendar system they're working in anyway.
Currently there is no real text handling support for this type.
DayOfWeek
Declaration
public int DayOfWeek { get; }
Property Value
Type | Description |
---|---|
Int32 |
Remarks
See Also
DayOfYear
Declaration
public int DayOfYear { get; }
Property Value
Type | Description |
---|---|
Int32 |
Remarks
Although ZonedDateTime includes both local and global concepts, it only supports duration-based - and not calendar-based - arithmetic. This avoids ambiguities and skipped date/time values becoming a problem within a series of calculations; instead, these can be considered just once, at the point of conversion to a ZonedDateTime.
Comparisons of values can be handled in a way which is either calendar and zone sensitive or insensitive. Noda Time implements all the operators (and the Equals(ZonedDateTime) method) such that all operators other than Inequality(ZonedDateTime, ZonedDateTime) will return false if asked to compare two values in different calendar systems or time zones.
However, the CompareTo(ZonedDateTime) method (implementing IComparable<T>) is calendar and zone insensitive; it compares the two global instants in terms of when they actually occurred.
It's unclear at the time of this writing whether this is the most appropriate approach, and it may change in future versions. In general, it would be a good idea for users to avoid comparing dates in different calendar systems, and indeed most users are unlikely to ever explicitly consider which calendar system they're working in anyway.
Currently there is no real text handling support for this type.
Era
Declaration
public Era Era { get; }
Property Value
Type | Description |
---|---|
Era |
Remarks
Although ZonedDateTime includes both local and global concepts, it only supports duration-based - and not calendar-based - arithmetic. This avoids ambiguities and skipped date/time values becoming a problem within a series of calculations; instead, these can be considered just once, at the point of conversion to a ZonedDateTime.
Comparisons of values can be handled in a way which is either calendar and zone sensitive or insensitive. Noda Time implements all the operators (and the Equals(ZonedDateTime) method) such that all operators other than Inequality(ZonedDateTime, ZonedDateTime) will return false if asked to compare two values in different calendar systems or time zones.
However, the CompareTo(ZonedDateTime) method (implementing IComparable<T>) is calendar and zone insensitive; it compares the two global instants in terms of when they actually occurred.
It's unclear at the time of this writing whether this is the most appropriate approach, and it may change in future versions. In general, it would be a good idea for users to avoid comparing dates in different calendar systems, and indeed most users are unlikely to ever explicitly consider which calendar system they're working in anyway.
Currently there is no real text handling support for this type.
Hour
Declaration
public int Hour { get; }
Property Value
Type | Description |
---|---|
Int32 |
Remarks
Although ZonedDateTime includes both local and global concepts, it only supports duration-based - and not calendar-based - arithmetic. This avoids ambiguities and skipped date/time values becoming a problem within a series of calculations; instead, these can be considered just once, at the point of conversion to a ZonedDateTime.
Comparisons of values can be handled in a way which is either calendar and zone sensitive or insensitive. Noda Time implements all the operators (and the Equals(ZonedDateTime) method) such that all operators other than Inequality(ZonedDateTime, ZonedDateTime) will return false if asked to compare two values in different calendar systems or time zones.
However, the CompareTo(ZonedDateTime) method (implementing IComparable<T>) is calendar and zone insensitive; it compares the two global instants in terms of when they actually occurred.
It's unclear at the time of this writing whether this is the most appropriate approach, and it may change in future versions. In general, it would be a good idea for users to avoid comparing dates in different calendar systems, and indeed most users are unlikely to ever explicitly consider which calendar system they're working in anyway.
Currently there is no real text handling support for this type.
IsoDayOfWeek
Declaration
public IsoDayOfWeek IsoDayOfWeek { get; }
Property Value
Type | Description |
---|---|
IsoDayOfWeek |
Remarks
Although ZonedDateTime includes both local and global concepts, it only supports duration-based - and not calendar-based - arithmetic. This avoids ambiguities and skipped date/time values becoming a problem within a series of calculations; instead, these can be considered just once, at the point of conversion to a ZonedDateTime.
Comparisons of values can be handled in a way which is either calendar and zone sensitive or insensitive. Noda Time implements all the operators (and the Equals(ZonedDateTime) method) such that all operators other than Inequality(ZonedDateTime, ZonedDateTime) will return false if asked to compare two values in different calendar systems or time zones.
However, the CompareTo(ZonedDateTime) method (implementing IComparable<T>) is calendar and zone insensitive; it compares the two global instants in terms of when they actually occurred.
It's unclear at the time of this writing whether this is the most appropriate approach, and it may change in future versions. In general, it would be a good idea for users to avoid comparing dates in different calendar systems, and indeed most users are unlikely to ever explicitly consider which calendar system they're working in anyway.
Currently there is no real text handling support for this type.
Exceptions
Type | Condition |
---|---|
System.InvalidOperationException | The underlying calendar doesn't use ISO days of the week. |
See Also
LocalDateTime
Declaration
public LocalDateTime LocalDateTime { get; }
Property Value
Type | Description |
---|---|
LocalDateTime |
Remarks
Although ZonedDateTime includes both local and global concepts, it only supports duration-based - and not calendar-based - arithmetic. This avoids ambiguities and skipped date/time values becoming a problem within a series of calculations; instead, these can be considered just once, at the point of conversion to a ZonedDateTime.
Comparisons of values can be handled in a way which is either calendar and zone sensitive or insensitive. Noda Time implements all the operators (and the Equals(ZonedDateTime) method) such that all operators other than Inequality(ZonedDateTime, ZonedDateTime) will return false if asked to compare two values in different calendar systems or time zones.
However, the CompareTo(ZonedDateTime) method (implementing IComparable<T>) is calendar and zone insensitive; it compares the two global instants in terms of when they actually occurred.
It's unclear at the time of this writing whether this is the most appropriate approach, and it may change in future versions. In general, it would be a good idea for users to avoid comparing dates in different calendar systems, and indeed most users are unlikely to ever explicitly consider which calendar system they're working in anyway.
Currently there is no real text handling support for this type.
Millisecond
Declaration
public int Millisecond { get; }
Property Value
Type | Description |
---|---|
Int32 |
Remarks
Although ZonedDateTime includes both local and global concepts, it only supports duration-based - and not calendar-based - arithmetic. This avoids ambiguities and skipped date/time values becoming a problem within a series of calculations; instead, these can be considered just once, at the point of conversion to a ZonedDateTime.
Comparisons of values can be handled in a way which is either calendar and zone sensitive or insensitive. Noda Time implements all the operators (and the Equals(ZonedDateTime) method) such that all operators other than Inequality(ZonedDateTime, ZonedDateTime) will return false if asked to compare two values in different calendar systems or time zones.
However, the CompareTo(ZonedDateTime) method (implementing IComparable<T>) is calendar and zone insensitive; it compares the two global instants in terms of when they actually occurred.
It's unclear at the time of this writing whether this is the most appropriate approach, and it may change in future versions. In general, it would be a good idea for users to avoid comparing dates in different calendar systems, and indeed most users are unlikely to ever explicitly consider which calendar system they're working in anyway.
Currently there is no real text handling support for this type.
Minute
Declaration
public int Minute { get; }
Property Value
Type | Description |
---|---|
Int32 |
Remarks
Although ZonedDateTime includes both local and global concepts, it only supports duration-based - and not calendar-based - arithmetic. This avoids ambiguities and skipped date/time values becoming a problem within a series of calculations; instead, these can be considered just once, at the point of conversion to a ZonedDateTime.
Comparisons of values can be handled in a way which is either calendar and zone sensitive or insensitive. Noda Time implements all the operators (and the Equals(ZonedDateTime) method) such that all operators other than Inequality(ZonedDateTime, ZonedDateTime) will return false if asked to compare two values in different calendar systems or time zones.
However, the CompareTo(ZonedDateTime) method (implementing IComparable<T>) is calendar and zone insensitive; it compares the two global instants in terms of when they actually occurred.
It's unclear at the time of this writing whether this is the most appropriate approach, and it may change in future versions. In general, it would be a good idea for users to avoid comparing dates in different calendar systems, and indeed most users are unlikely to ever explicitly consider which calendar system they're working in anyway.
Currently there is no real text handling support for this type.
Month
Declaration
public int Month { get; }
Property Value
Type | Description |
---|---|
Int32 |
Remarks
Although ZonedDateTime includes both local and global concepts, it only supports duration-based - and not calendar-based - arithmetic. This avoids ambiguities and skipped date/time values becoming a problem within a series of calculations; instead, these can be considered just once, at the point of conversion to a ZonedDateTime.
Comparisons of values can be handled in a way which is either calendar and zone sensitive or insensitive. Noda Time implements all the operators (and the Equals(ZonedDateTime) method) such that all operators other than Inequality(ZonedDateTime, ZonedDateTime) will return false if asked to compare two values in different calendar systems or time zones.
However, the CompareTo(ZonedDateTime) method (implementing IComparable<T>) is calendar and zone insensitive; it compares the two global instants in terms of when they actually occurred.
It's unclear at the time of this writing whether this is the most appropriate approach, and it may change in future versions. In general, it would be a good idea for users to avoid comparing dates in different calendar systems, and indeed most users are unlikely to ever explicitly consider which calendar system they're working in anyway.
Currently there is no real text handling support for this type.
Offset
Declaration
public Offset Offset { get; }
Property Value
Type | Description |
---|---|
Offset |
Remarks
Although ZonedDateTime includes both local and global concepts, it only supports duration-based - and not calendar-based - arithmetic. This avoids ambiguities and skipped date/time values becoming a problem within a series of calculations; instead, these can be considered just once, at the point of conversion to a ZonedDateTime.
Comparisons of values can be handled in a way which is either calendar and zone sensitive or insensitive. Noda Time implements all the operators (and the Equals(ZonedDateTime) method) such that all operators other than Inequality(ZonedDateTime, ZonedDateTime) will return false if asked to compare two values in different calendar systems or time zones.
However, the CompareTo(ZonedDateTime) method (implementing IComparable<T>) is calendar and zone insensitive; it compares the two global instants in terms of when they actually occurred.
It's unclear at the time of this writing whether this is the most appropriate approach, and it may change in future versions. In general, it would be a good idea for users to avoid comparing dates in different calendar systems, and indeed most users are unlikely to ever explicitly consider which calendar system they're working in anyway.
Currently there is no real text handling support for this type.
Second
Declaration
public int Second { get; }
Property Value
Type | Description |
---|---|
Int32 |
Remarks
Although ZonedDateTime includes both local and global concepts, it only supports duration-based - and not calendar-based - arithmetic. This avoids ambiguities and skipped date/time values becoming a problem within a series of calculations; instead, these can be considered just once, at the point of conversion to a ZonedDateTime.
Comparisons of values can be handled in a way which is either calendar and zone sensitive or insensitive. Noda Time implements all the operators (and the Equals(ZonedDateTime) method) such that all operators other than Inequality(ZonedDateTime, ZonedDateTime) will return false if asked to compare two values in different calendar systems or time zones.
However, the CompareTo(ZonedDateTime) method (implementing IComparable<T>) is calendar and zone insensitive; it compares the two global instants in terms of when they actually occurred.
It's unclear at the time of this writing whether this is the most appropriate approach, and it may change in future versions. In general, it would be a good idea for users to avoid comparing dates in different calendar systems, and indeed most users are unlikely to ever explicitly consider which calendar system they're working in anyway.
Currently there is no real text handling support for this type.
TickOfDay
Declaration
public long TickOfDay { get; }
Property Value
Type | Description |
---|---|
Int64 |
Remarks
Although ZonedDateTime includes both local and global concepts, it only supports duration-based - and not calendar-based - arithmetic. This avoids ambiguities and skipped date/time values becoming a problem within a series of calculations; instead, these can be considered just once, at the point of conversion to a ZonedDateTime.
Comparisons of values can be handled in a way which is either calendar and zone sensitive or insensitive. Noda Time implements all the operators (and the Equals(ZonedDateTime) method) such that all operators other than Inequality(ZonedDateTime, ZonedDateTime) will return false if asked to compare two values in different calendar systems or time zones.
However, the CompareTo(ZonedDateTime) method (implementing IComparable<T>) is calendar and zone insensitive; it compares the two global instants in terms of when they actually occurred.
It's unclear at the time of this writing whether this is the most appropriate approach, and it may change in future versions. In general, it would be a good idea for users to avoid comparing dates in different calendar systems, and indeed most users are unlikely to ever explicitly consider which calendar system they're working in anyway.
Currently there is no real text handling support for this type.
TickOfSecond
Declaration
public int TickOfSecond { get; }
Property Value
Type | Description |
---|---|
Int32 |
Remarks
Although ZonedDateTime includes both local and global concepts, it only supports duration-based - and not calendar-based - arithmetic. This avoids ambiguities and skipped date/time values becoming a problem within a series of calculations; instead, these can be considered just once, at the point of conversion to a ZonedDateTime.
Comparisons of values can be handled in a way which is either calendar and zone sensitive or insensitive. Noda Time implements all the operators (and the Equals(ZonedDateTime) method) such that all operators other than Inequality(ZonedDateTime, ZonedDateTime) will return false if asked to compare two values in different calendar systems or time zones.
However, the CompareTo(ZonedDateTime) method (implementing IComparable<T>) is calendar and zone insensitive; it compares the two global instants in terms of when they actually occurred.
It's unclear at the time of this writing whether this is the most appropriate approach, and it may change in future versions. In general, it would be a good idea for users to avoid comparing dates in different calendar systems, and indeed most users are unlikely to ever explicitly consider which calendar system they're working in anyway.
Currently there is no real text handling support for this type.
TimeOfDay
Declaration
public LocalTime TimeOfDay { get; }
Property Value
Type | Description |
---|---|
LocalTime |
Remarks
Although ZonedDateTime includes both local and global concepts, it only supports duration-based - and not calendar-based - arithmetic. This avoids ambiguities and skipped date/time values becoming a problem within a series of calculations; instead, these can be considered just once, at the point of conversion to a ZonedDateTime.
Comparisons of values can be handled in a way which is either calendar and zone sensitive or insensitive. Noda Time implements all the operators (and the Equals(ZonedDateTime) method) such that all operators other than Inequality(ZonedDateTime, ZonedDateTime) will return false if asked to compare two values in different calendar systems or time zones.
However, the CompareTo(ZonedDateTime) method (implementing IComparable<T>) is calendar and zone insensitive; it compares the two global instants in terms of when they actually occurred.
It's unclear at the time of this writing whether this is the most appropriate approach, and it may change in future versions. In general, it would be a good idea for users to avoid comparing dates in different calendar systems, and indeed most users are unlikely to ever explicitly consider which calendar system they're working in anyway.
Currently there is no real text handling support for this type.
WeekOfWeekYear
Declaration
public int WeekOfWeekYear { get; }
Property Value
Type | Description |
---|---|
Int32 |
Remarks
Although ZonedDateTime includes both local and global concepts, it only supports duration-based - and not calendar-based - arithmetic. This avoids ambiguities and skipped date/time values becoming a problem within a series of calculations; instead, these can be considered just once, at the point of conversion to a ZonedDateTime.
Comparisons of values can be handled in a way which is either calendar and zone sensitive or insensitive. Noda Time implements all the operators (and the Equals(ZonedDateTime) method) such that all operators other than Inequality(ZonedDateTime, ZonedDateTime) will return false if asked to compare two values in different calendar systems or time zones.
However, the CompareTo(ZonedDateTime) method (implementing IComparable<T>) is calendar and zone insensitive; it compares the two global instants in terms of when they actually occurred.
It's unclear at the time of this writing whether this is the most appropriate approach, and it may change in future versions. In general, it would be a good idea for users to avoid comparing dates in different calendar systems, and indeed most users are unlikely to ever explicitly consider which calendar system they're working in anyway.
Currently there is no real text handling support for this type.
WeekYear
Declaration
public int WeekYear { get; }
Property Value
Type | Description |
---|---|
Int32 |
Remarks
The WeekYear is the year that matches with the WeekOfWeekYear field. In the standard ISO-8601 week algorithm, the first week of the year is that in which at least 4 days are in the year. As a result of this definition, day 1 of the first week may be in the previous year. The WeekYear allows you to query the effective year for that day.
For example, January 1st 2011 was a Saturday, so only two days of that week (Saturday and Sunday) were in 2011. Therefore January 1st is part of week 52 of WeekYear 2010. Conversely, December 31st 2012 is a Monday, so is part of week 1 of WeekYear 2013.
Year
Declaration
public int Year { get; }
Property Value
Type | Description |
---|---|
Int32 |
Remarks
YearOfCentury
Declaration
public int YearOfCentury { get; }
Property Value
Type | Description |
---|---|
Int32 |
Remarks
YearOfEra
Declaration
public int YearOfEra { get; }
Property Value
Type | Description |
---|---|
Int32 |
Remarks
Although ZonedDateTime includes both local and global concepts, it only supports duration-based - and not calendar-based - arithmetic. This avoids ambiguities and skipped date/time values becoming a problem within a series of calculations; instead, these can be considered just once, at the point of conversion to a ZonedDateTime.
Comparisons of values can be handled in a way which is either calendar and zone sensitive or insensitive. Noda Time implements all the operators (and the Equals(ZonedDateTime) method) such that all operators other than Inequality(ZonedDateTime, ZonedDateTime) will return false if asked to compare two values in different calendar systems or time zones.
However, the CompareTo(ZonedDateTime) method (implementing IComparable<T>) is calendar and zone insensitive; it compares the two global instants in terms of when they actually occurred.
It's unclear at the time of this writing whether this is the most appropriate approach, and it may change in future versions. In general, it would be a good idea for users to avoid comparing dates in different calendar systems, and indeed most users are unlikely to ever explicitly consider which calendar system they're working in anyway.
Currently there is no real text handling support for this type.
Zone
Declaration
public DateTimeZone Zone { get; }
Property Value
Type | Description |
---|---|
DateTimeZone |
Remarks
Although ZonedDateTime includes both local and global concepts, it only supports duration-based - and not calendar-based - arithmetic. This avoids ambiguities and skipped date/time values becoming a problem within a series of calculations; instead, these can be considered just once, at the point of conversion to a ZonedDateTime.
Comparisons of values can be handled in a way which is either calendar and zone sensitive or insensitive. Noda Time implements all the operators (and the Equals(ZonedDateTime) method) such that all operators other than Inequality(ZonedDateTime, ZonedDateTime) will return false if asked to compare two values in different calendar systems or time zones.
However, the CompareTo(ZonedDateTime) method (implementing IComparable<T>) is calendar and zone insensitive; it compares the two global instants in terms of when they actually occurred.
It's unclear at the time of this writing whether this is the most appropriate approach, and it may change in future versions. In general, it would be a good idea for users to avoid comparing dates in different calendar systems, and indeed most users are unlikely to ever explicitly consider which calendar system they're working in anyway.
Currently there is no real text handling support for this type.
Methods
Add(ZonedDateTime, Duration)
operator+()
.
Declaration
public static ZonedDateTime Add(ZonedDateTime zonedDateTime, Duration duration)
Parameters
Type | Name | Description |
---|---|---|
ZonedDateTime | zonedDateTime | The value to add the duration to. |
Duration | duration | The duration to add |
Returns
Type | Description |
---|---|
ZonedDateTime | A new value with the time advanced by the given duration, in the same calendar system and time zone. |
Remarks
Although ZonedDateTime includes both local and global concepts, it only supports duration-based - and not calendar-based - arithmetic. This avoids ambiguities and skipped date/time values becoming a problem within a series of calculations; instead, these can be considered just once, at the point of conversion to a ZonedDateTime.
Comparisons of values can be handled in a way which is either calendar and zone sensitive or insensitive. Noda Time implements all the operators (and the Equals(ZonedDateTime) method) such that all operators other than Inequality(ZonedDateTime, ZonedDateTime) will return false if asked to compare two values in different calendar systems or time zones.
However, the CompareTo(ZonedDateTime) method (implementing IComparable<T>) is calendar and zone insensitive; it compares the two global instants in terms of when they actually occurred.
It's unclear at the time of this writing whether this is the most appropriate approach, and it may change in future versions. In general, it would be a good idea for users to avoid comparing dates in different calendar systems, and indeed most users are unlikely to ever explicitly consider which calendar system they're working in anyway.
Currently there is no real text handling support for this type.
CompareTo(ZonedDateTime)
Declaration
public int CompareTo(ZonedDateTime other)
Parameters
Type | Name | Description |
---|---|---|
ZonedDateTime | other | The other zoned date/time to compare this one with |
Returns
Type | Description |
---|---|
Int32 | A value less than zero if the instant represented by this zoned date/time is earlier than the one in
other ; zero if the instant is the same as the one in other ;
a value greater than zero if the instant is later than the one in other . |
Remarks
Equals(ZonedDateTime)
Declaration
public bool Equals(ZonedDateTime other)
Parameters
Type | Name | Description |
---|---|---|
ZonedDateTime | other | An object to compare with this object. |
Returns
Type | Description |
---|---|
System.Boolean |
true if the current object is equal to the other parameter; otherwise, false.
|
Remarks
Although ZonedDateTime includes both local and global concepts, it only supports duration-based - and not calendar-based - arithmetic. This avoids ambiguities and skipped date/time values becoming a problem within a series of calculations; instead, these can be considered just once, at the point of conversion to a ZonedDateTime.
Comparisons of values can be handled in a way which is either calendar and zone sensitive or insensitive. Noda Time implements all the operators (and the Equals(ZonedDateTime) method) such that all operators other than Inequality(ZonedDateTime, ZonedDateTime) will return false if asked to compare two values in different calendar systems or time zones.
However, the CompareTo(ZonedDateTime) method (implementing IComparable<T>) is calendar and zone insensitive; it compares the two global instants in terms of when they actually occurred.
It's unclear at the time of this writing whether this is the most appropriate approach, and it may change in future versions. In general, it would be a good idea for users to avoid comparing dates in different calendar systems, and indeed most users are unlikely to ever explicitly consider which calendar system they're working in anyway.
Currently there is no real text handling support for this type.
Equals(Object)
Declaration
public override bool Equals(object obj)
Parameters
Type | Name | Description |
---|---|---|
System.Object | obj | Another object to compare to. |
Returns
Type | Description |
---|---|
System.Boolean |
true if obj and this instance are the same type and represent the same value; otherwise, false.
|
Overrides
Remarks
Although ZonedDateTime includes both local and global concepts, it only supports duration-based - and not calendar-based - arithmetic. This avoids ambiguities and skipped date/time values becoming a problem within a series of calculations; instead, these can be considered just once, at the point of conversion to a ZonedDateTime.
Comparisons of values can be handled in a way which is either calendar and zone sensitive or insensitive. Noda Time implements all the operators (and the Equals(ZonedDateTime) method) such that all operators other than Inequality(ZonedDateTime, ZonedDateTime) will return false if asked to compare two values in different calendar systems or time zones.
However, the CompareTo(ZonedDateTime) method (implementing IComparable<T>) is calendar and zone insensitive; it compares the two global instants in terms of when they actually occurred.
It's unclear at the time of this writing whether this is the most appropriate approach, and it may change in future versions. In general, it would be a good idea for users to avoid comparing dates in different calendar systems, and indeed most users are unlikely to ever explicitly consider which calendar system they're working in anyway.
Currently there is no real text handling support for this type.
FromDateTimeOffset(DateTimeOffset)
Declaration
public static ZonedDateTime FromDateTimeOffset(DateTimeOffset dateTimeOffset)
Parameters
Type | Name | Description |
---|---|---|
System.DateTimeOffset | dateTimeOffset | Date and time value with an offset. |
Returns
Type | Description |
---|---|
ZonedDateTime | A ZonedDateTime value representing the same instant in time as the given System.DateTimeOffset. |
Remarks
Although ZonedDateTime includes both local and global concepts, it only supports duration-based - and not calendar-based - arithmetic. This avoids ambiguities and skipped date/time values becoming a problem within a series of calculations; instead, these can be considered just once, at the point of conversion to a ZonedDateTime.
Comparisons of values can be handled in a way which is either calendar and zone sensitive or insensitive. Noda Time implements all the operators (and the Equals(ZonedDateTime) method) such that all operators other than Inequality(ZonedDateTime, ZonedDateTime) will return false if asked to compare two values in different calendar systems or time zones.
However, the CompareTo(ZonedDateTime) method (implementing IComparable<T>) is calendar and zone insensitive; it compares the two global instants in terms of when they actually occurred.
It's unclear at the time of this writing whether this is the most appropriate approach, and it may change in future versions. In general, it would be a good idea for users to avoid comparing dates in different calendar systems, and indeed most users are unlikely to ever explicitly consider which calendar system they're working in anyway.
Currently there is no real text handling support for this type.
GetHashCode()
Declaration
public override int GetHashCode()
Returns
Type | Description |
---|---|
Int32 | A 32-bit signed integer that is the hash code for this instance. |
Overrides
Remarks
Although ZonedDateTime includes both local and global concepts, it only supports duration-based - and not calendar-based - arithmetic. This avoids ambiguities and skipped date/time values becoming a problem within a series of calculations; instead, these can be considered just once, at the point of conversion to a ZonedDateTime.
Comparisons of values can be handled in a way which is either calendar and zone sensitive or insensitive. Noda Time implements all the operators (and the Equals(ZonedDateTime) method) such that all operators other than Inequality(ZonedDateTime, ZonedDateTime) will return false if asked to compare two values in different calendar systems or time zones.
However, the CompareTo(ZonedDateTime) method (implementing IComparable<T>) is calendar and zone insensitive; it compares the two global instants in terms of when they actually occurred.
It's unclear at the time of this writing whether this is the most appropriate approach, and it may change in future versions. In general, it would be a good idea for users to avoid comparing dates in different calendar systems, and indeed most users are unlikely to ever explicitly consider which calendar system they're working in anyway.
Currently there is no real text handling support for this type.
Minus(Duration)
operator-()
.
Declaration
public ZonedDateTime Minus(Duration duration)
Parameters
Type | Name | Description |
---|---|---|
Duration | duration | The duration to subtract |
Returns
Type | Description |
---|---|
ZonedDateTime | A new ZonedDateTime representing the result of the subtraction. |
Remarks
Although ZonedDateTime includes both local and global concepts, it only supports duration-based - and not calendar-based - arithmetic. This avoids ambiguities and skipped date/time values becoming a problem within a series of calculations; instead, these can be considered just once, at the point of conversion to a ZonedDateTime.
Comparisons of values can be handled in a way which is either calendar and zone sensitive or insensitive. Noda Time implements all the operators (and the Equals(ZonedDateTime) method) such that all operators other than Inequality(ZonedDateTime, ZonedDateTime) will return false if asked to compare two values in different calendar systems or time zones.
However, the CompareTo(ZonedDateTime) method (implementing IComparable<T>) is calendar and zone insensitive; it compares the two global instants in terms of when they actually occurred.
It's unclear at the time of this writing whether this is the most appropriate approach, and it may change in future versions. In general, it would be a good idea for users to avoid comparing dates in different calendar systems, and indeed most users are unlikely to ever explicitly consider which calendar system they're working in anyway.
Currently there is no real text handling support for this type.
Plus(Duration)
operator+()
.
Declaration
public ZonedDateTime Plus(Duration duration)
Parameters
Type | Name | Description |
---|---|---|
Duration | duration | The duration to add |
Returns
Type | Description |
---|---|
ZonedDateTime | A new ZonedDateTime representing the result of the addition. |
Remarks
Although ZonedDateTime includes both local and global concepts, it only supports duration-based - and not calendar-based - arithmetic. This avoids ambiguities and skipped date/time values becoming a problem within a series of calculations; instead, these can be considered just once, at the point of conversion to a ZonedDateTime.
Comparisons of values can be handled in a way which is either calendar and zone sensitive or insensitive. Noda Time implements all the operators (and the Equals(ZonedDateTime) method) such that all operators other than Inequality(ZonedDateTime, ZonedDateTime) will return false if asked to compare two values in different calendar systems or time zones.
However, the CompareTo(ZonedDateTime) method (implementing IComparable<T>) is calendar and zone insensitive; it compares the two global instants in terms of when they actually occurred.
It's unclear at the time of this writing whether this is the most appropriate approach, and it may change in future versions. In general, it would be a good idea for users to avoid comparing dates in different calendar systems, and indeed most users are unlikely to ever explicitly consider which calendar system they're working in anyway.
Currently there is no real text handling support for this type.
Subtract(ZonedDateTime, Duration)
operator-()
.
Declaration
public static ZonedDateTime Subtract(ZonedDateTime zonedDateTime, Duration duration)
Parameters
Type | Name | Description |
---|---|---|
ZonedDateTime | zonedDateTime | The value to subtract the duration from. |
Duration | duration | The duration to subtract. |
Returns
Type | Description |
---|---|
ZonedDateTime | A new value with the time "rewound" by the given duration, in the same calendar system and time zone. |
Remarks
Although ZonedDateTime includes both local and global concepts, it only supports duration-based - and not calendar-based - arithmetic. This avoids ambiguities and skipped date/time values becoming a problem within a series of calculations; instead, these can be considered just once, at the point of conversion to a ZonedDateTime.
Comparisons of values can be handled in a way which is either calendar and zone sensitive or insensitive. Noda Time implements all the operators (and the Equals(ZonedDateTime) method) such that all operators other than Inequality(ZonedDateTime, ZonedDateTime) will return false if asked to compare two values in different calendar systems or time zones.
However, the CompareTo(ZonedDateTime) method (implementing IComparable<T>) is calendar and zone insensitive; it compares the two global instants in terms of when they actually occurred.
It's unclear at the time of this writing whether this is the most appropriate approach, and it may change in future versions. In general, it would be a good idea for users to avoid comparing dates in different calendar systems, and indeed most users are unlikely to ever explicitly consider which calendar system they're working in anyway.
Currently there is no real text handling support for this type.
ToDateTimeOffset()
Declaration
public DateTimeOffset ToDateTimeOffset()
Returns
Type | Description |
---|---|
System.DateTimeOffset | A System.DateTimeOffset representation of this value. |
Remarks
ToDateTimeUnspecified()
Declaration
public DateTime ToDateTimeUnspecified()
Returns
Type | Description |
---|---|
DateTime | A DateTime representation of this value with an "unspecified" kind, with the same local date and time as this value. |
Remarks
ToDateTimeUtc()
Declaration
public DateTime ToDateTimeUtc()
Returns
Type | Description |
---|---|
DateTime | A DateTime representation of this value with a "universal" kind, with the same instant of time as this value. |
Remarks
Although ZonedDateTime includes both local and global concepts, it only supports duration-based - and not calendar-based - arithmetic. This avoids ambiguities and skipped date/time values becoming a problem within a series of calculations; instead, these can be considered just once, at the point of conversion to a ZonedDateTime.
Comparisons of values can be handled in a way which is either calendar and zone sensitive or insensitive. Noda Time implements all the operators (and the Equals(ZonedDateTime) method) such that all operators other than Inequality(ZonedDateTime, ZonedDateTime) will return false if asked to compare two values in different calendar systems or time zones.
However, the CompareTo(ZonedDateTime) method (implementing IComparable<T>) is calendar and zone insensitive; it compares the two global instants in terms of when they actually occurred.
It's unclear at the time of this writing whether this is the most appropriate approach, and it may change in future versions. In general, it would be a good idea for users to avoid comparing dates in different calendar systems, and indeed most users are unlikely to ever explicitly consider which calendar system they're working in anyway.
Currently there is no real text handling support for this type.
ToInstant()
Declaration
public Instant ToInstant()
Returns
Type | Description |
---|---|
Instant | The instant corresponding to this value. |
Remarks
ZonedDateTime
remembers the actual offset from UTC to local time,
so it always knows the exact instant represented.
ToOffsetDateTime()
Declaration
public OffsetDateTime ToOffsetDateTime()
Returns
Type | Description |
---|---|
OffsetDateTime | An OffsetDateTime with the same local date/time and offset as this value. |
Remarks
Although ZonedDateTime includes both local and global concepts, it only supports duration-based - and not calendar-based - arithmetic. This avoids ambiguities and skipped date/time values becoming a problem within a series of calculations; instead, these can be considered just once, at the point of conversion to a ZonedDateTime.
Comparisons of values can be handled in a way which is either calendar and zone sensitive or insensitive. Noda Time implements all the operators (and the Equals(ZonedDateTime) method) such that all operators other than Inequality(ZonedDateTime, ZonedDateTime) will return false if asked to compare two values in different calendar systems or time zones.
However, the CompareTo(ZonedDateTime) method (implementing IComparable<T>) is calendar and zone insensitive; it compares the two global instants in terms of when they actually occurred.
It's unclear at the time of this writing whether this is the most appropriate approach, and it may change in future versions. In general, it would be a good idea for users to avoid comparing dates in different calendar systems, and indeed most users are unlikely to ever explicitly consider which calendar system they're working in anyway.
Currently there is no real text handling support for this type.
ToString()
ToString
method of each component is used,
which will render the local time and offset in the "general" pattern for the current thread's culture,
and simply include the ID for most time zone implementations.
Declaration
public override string ToString()
Returns
Type | Description |
---|---|
String | A string representation of this value. |
Overrides
Remarks
This representation is a temporary measure until full support for parsing and formatting ZonedDateTime values is implemented. It is provided in order to make diagnostics simpler, but is likely to be changed in future releases.
WithZone(DateTimeZone)
Declaration
public ZonedDateTime WithZone(DateTimeZone targetZone)
Parameters
Type | Name | Description |
---|---|---|
DateTimeZone | targetZone | The target time zone to convert to. |
Returns
Type | Description |
---|---|
ZonedDateTime | A new value in the target time zone. |
Remarks
Although ZonedDateTime includes both local and global concepts, it only supports duration-based - and not calendar-based - arithmetic. This avoids ambiguities and skipped date/time values becoming a problem within a series of calculations; instead, these can be considered just once, at the point of conversion to a ZonedDateTime.
Comparisons of values can be handled in a way which is either calendar and zone sensitive or insensitive. Noda Time implements all the operators (and the Equals(ZonedDateTime) method) such that all operators other than Inequality(ZonedDateTime, ZonedDateTime) will return false if asked to compare two values in different calendar systems or time zones.
However, the CompareTo(ZonedDateTime) method (implementing IComparable<T>) is calendar and zone insensitive; it compares the two global instants in terms of when they actually occurred.
It's unclear at the time of this writing whether this is the most appropriate approach, and it may change in future versions. In general, it would be a good idea for users to avoid comparing dates in different calendar systems, and indeed most users are unlikely to ever explicitly consider which calendar system they're working in anyway.
Currently there is no real text handling support for this type.
Exceptions
Type | Condition |
---|---|
ArgumentNullException | targetZone is null. |
Operators
Addition(ZonedDateTime, Duration)
Declaration
public static ZonedDateTime operator +(ZonedDateTime zonedDateTime, Duration duration)
Parameters
Type | Name | Description |
---|---|---|
ZonedDateTime | zonedDateTime | The ZonedDateTime to add the duration to. |
Duration | duration | The duration to add. |
Returns
Type | Description |
---|---|
ZonedDateTime | A new value with the time advanced by the given duration, in the same calendar system and time zone. |
Remarks
Equality(ZonedDateTime, ZonedDateTime)
Declaration
public static bool operator ==(ZonedDateTime left, ZonedDateTime right)
Parameters
Type | Name | Description |
---|---|---|
ZonedDateTime | left | The first value to compare |
ZonedDateTime | right | The second value to compare |
Returns
Type | Description |
---|---|
System.Boolean | True if the two operands are equal according to Equals(ZonedDateTime); false otherwise |
Remarks
Although ZonedDateTime includes both local and global concepts, it only supports duration-based - and not calendar-based - arithmetic. This avoids ambiguities and skipped date/time values becoming a problem within a series of calculations; instead, these can be considered just once, at the point of conversion to a ZonedDateTime.
Comparisons of values can be handled in a way which is either calendar and zone sensitive or insensitive. Noda Time implements all the operators (and the Equals(ZonedDateTime) method) such that all operators other than Inequality(ZonedDateTime, ZonedDateTime) will return false if asked to compare two values in different calendar systems or time zones.
However, the CompareTo(ZonedDateTime) method (implementing IComparable<T>) is calendar and zone insensitive; it compares the two global instants in terms of when they actually occurred.
It's unclear at the time of this writing whether this is the most appropriate approach, and it may change in future versions. In general, it would be a good idea for users to avoid comparing dates in different calendar systems, and indeed most users are unlikely to ever explicitly consider which calendar system they're working in anyway.
Currently there is no real text handling support for this type.
GreaterThan(ZonedDateTime, ZonedDateTime)
Declaration
public static bool operator>(ZonedDateTime lhs, ZonedDateTime rhs)
Parameters
Type | Name | Description |
---|---|---|
ZonedDateTime | lhs | First operand of the comparison |
ZonedDateTime | rhs | Second operand of the comparison |
Returns
Type | Description |
---|---|
System.Boolean | true if the lhs is strictly later than rhs , false otherwise. |
Remarks
GreaterThanOrEqual(ZonedDateTime, ZonedDateTime)
Declaration
public static bool operator >=(ZonedDateTime lhs, ZonedDateTime rhs)
Parameters
Type | Name | Description |
---|---|---|
ZonedDateTime | lhs | First operand of the comparison |
ZonedDateTime | rhs | Second operand of the comparison |
Returns
Type | Description |
---|---|
System.Boolean | true if the lhs is later than or equal to rhs , false otherwise. |
Remarks
Inequality(ZonedDateTime, ZonedDateTime)
Declaration
public static bool operator !=(ZonedDateTime left, ZonedDateTime right)
Parameters
Type | Name | Description |
---|---|---|
ZonedDateTime | left | The first value to compare |
ZonedDateTime | right | The second value to compare |
Returns
Type | Description |
---|---|
System.Boolean | False if the two operands are equal according to Equals(ZonedDateTime); true otherwise |
Remarks
Although ZonedDateTime includes both local and global concepts, it only supports duration-based - and not calendar-based - arithmetic. This avoids ambiguities and skipped date/time values becoming a problem within a series of calculations; instead, these can be considered just once, at the point of conversion to a ZonedDateTime.
Comparisons of values can be handled in a way which is either calendar and zone sensitive or insensitive. Noda Time implements all the operators (and the Equals(ZonedDateTime) method) such that all operators other than Inequality(ZonedDateTime, ZonedDateTime) will return false if asked to compare two values in different calendar systems or time zones.
However, the CompareTo(ZonedDateTime) method (implementing IComparable<T>) is calendar and zone insensitive; it compares the two global instants in terms of when they actually occurred.
It's unclear at the time of this writing whether this is the most appropriate approach, and it may change in future versions. In general, it would be a good idea for users to avoid comparing dates in different calendar systems, and indeed most users are unlikely to ever explicitly consider which calendar system they're working in anyway.
Currently there is no real text handling support for this type.
LessThan(ZonedDateTime, ZonedDateTime)
Declaration
public static bool operator <(ZonedDateTime lhs, ZonedDateTime rhs)
Parameters
Type | Name | Description |
---|---|---|
ZonedDateTime | lhs | First operand of the comparison |
ZonedDateTime | rhs | Second operand of the comparison |
Returns
Type | Description |
---|---|
System.Boolean | true if the lhs is strictly earlier than rhs , false otherwise. |
Remarks
LessThanOrEqual(ZonedDateTime, ZonedDateTime)
Declaration
public static bool operator <=(ZonedDateTime lhs, ZonedDateTime rhs)
Parameters
Type | Name | Description |
---|---|---|
ZonedDateTime | lhs | First operand of the comparison |
ZonedDateTime | rhs | Second operand of the comparison |
Returns
Type | Description |
---|---|
System.Boolean | true if the lhs is earlier than or equal to rhs , false otherwise. |
Remarks
Subtraction(ZonedDateTime, Duration)
Declaration
public static ZonedDateTime operator -(ZonedDateTime zonedDateTime, Duration duration)
Parameters
Type | Name | Description |
---|---|---|
ZonedDateTime | zonedDateTime | The value to subtract the duration from. |
Duration | duration | The duration to subtract. |
Returns
Type | Description |
---|---|
ZonedDateTime | A new value with the time "rewound" by the given duration, in the same calendar system and time zone. |
Remarks
Explicit Interface Implementations
IComparable.CompareTo(Object)
Declaration
int IComparable.CompareTo(object obj)
Parameters
Type | Name | Description |
---|---|---|
System.Object | obj | The object to compare this value with. |
Returns
Type | Description |
---|---|
Int32 | The result of comparing this ZonedDateTime with another one; see CompareTo(ZonedDateTime) for general details.
If obj is null, this method returns a value greater than 0.
|
Remarks
Exceptions
Type | Condition |
---|---|
ArgumentException | obj is non-null but does not refer to an instance of ZonedDateTime. |