Struct ZonedDateTime
Implements
Inherited Members
Namespace: NodaTime
Assembly: NodaTime.dll
Syntax
[Serializable]
public struct ZonedDateTime : IEquatable<ZonedDateTime>, IComparable<ZonedDateTime>, IComparable, IFormattable, IXmlSerializable, ISerializable
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.
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.
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.
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.
Exceptions
Type | Condition |
---|---|
ArgumentException | offset is not a valid offset at the given
local date and time. |
ArgumentNullException | zone is null. |
Properties
Calendar
Declaration
public CalendarSystem Calendar { get; }
Property Value
Type | Description |
---|---|
CalendarSystem |
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.
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.
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.
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.
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.
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.
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.
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.
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.
Exceptions
Type | Condition |
---|---|
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 |
---|---|
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.
Equals(Object)
Declaration
public override bool Equals(object obj)
Parameters
Type | Name | Description |
---|---|---|
Object | obj | Another object to compare to. |
Returns
Type | Description |
---|---|
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.
FromDateTimeOffset(DateTimeOffset)
Declaration
public static ZonedDateTime FromDateTimeOffset(DateTimeOffset dateTimeOffset)
Parameters
Type | Name | Description |
---|---|---|
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 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.
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.
GetZoneInterval()
Declaration
public ZoneInterval GetZoneInterval()
Returns
Type | Description |
---|---|
ZoneInterval | The ZoneInterval containing this value. |
Remarks
ZoneInterval
containing that instant.
IsDaylightSavingTime()
Declaration
public bool IsDaylightSavingTime()
Returns
Type | Description |
---|---|
Boolean | true if the zone interval containing this value has a non-zero savings
component; 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.
See Also
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.
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.
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.
ToDateTimeOffset()
Declaration
public DateTimeOffset ToDateTimeOffset()
Returns
Type | Description |
---|---|
DateTimeOffset | A 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.
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.
ToString()
Declaration
public override string ToString()
Returns
Type | Description |
---|---|
String | The value of the current instance in the default format pattern ("G"), using the current thread's culture to obtain a format provider. |
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.
ToString(String, IFormatProvider)
Declaration
public string ToString(string patternText, IFormatProvider formatProvider)
Parameters
Type | Name | Description |
---|---|---|
String | patternText | The String specifying the pattern to use, or null to use the default format pattern ("G"). |
IFormatProvider | formatProvider | The IFormatProvider to use when formatting the value, or null to use the current thread's culture to obtain a format provider. |
Returns
Type | Description |
---|---|
String | A String containing the value of the current instance in the specified format. |
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.
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.
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 |
---|---|
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.
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 |
---|---|
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 |
---|---|
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 |
---|---|
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.
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 |
---|---|
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 |
---|---|
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 |
---|---|---|
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. |
ISerializable.GetObjectData(SerializationInfo, StreamingContext)
Declaration
[SecurityCritical]
void ISerializable.GetObjectData(SerializationInfo info, StreamingContext context)
Parameters
Type | Name | Description |
---|---|---|
SerializationInfo | info | The SerializationInfo to populate with data. |
StreamingContext | context | The destination for this serialization. |
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.
IXmlSerializable.GetSchema()
Declaration
XmlSchema IXmlSerializable.GetSchema()
Returns
Type | Description |
---|---|
XmlSchema |
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.
IXmlSerializable.ReadXml(XmlReader)
Declaration
void IXmlSerializable.ReadXml(XmlReader reader)
Parameters
Type | Name | Description |
---|---|---|
XmlReader | reader |
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.
IXmlSerializable.WriteXml(XmlWriter)
Declaration
void IXmlSerializable.WriteXml(XmlWriter writer)
Parameters
Type | Name | Description |
---|---|---|
XmlWriter | writer |
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.