Serialization should consider DateTimeKind for UTC and non-UTC DateTimes #331
Comments
rianjs
pushed a commit
that referenced
this issue
Nov 7, 2017
- Use local time zones instead of doing everything in terms of UTC - Set and compare DateTimeKind during serialization and deserialization - Get rid of IsUniversalTime property in IDateTime - IsUtc property is get-only - AsSystemLocal no longer needs to do contortions to answer the question - ToTimeZone returns local or UTC time zones for BCL, serialization, and IANA zones - Better heuristics for determining whether a CalDateTime is UTC or local - TzId setter now does all the state maintenance for UTC vs local bookkeeping, and all other related properties are get-only - Consistent, ordinal string comparison in GetZone - Truncating parts of DateTimes doesn't suck anymore - Slightly better intellisense documentation - Fixed a broken unit test - Better local vs UTC time zone handling for Unit RRULEs with unit tests - Fixed a bug in the RecurrencePatternEvaluator where tzId wasn't taking into account - MatchTimeZone is less awkward and shorter Issues: #331, #330
rianjs
pushed a commit
that referenced
this issue
Nov 7, 2017
- Use local time zones instead of doing everything in terms of UTC - Set and compare DateTimeKind during serialization and deserialization - Get rid of IsUniversalTime property in IDateTime - IsUtc property is get-only - AsSystemLocal no longer needs to do contortions to answer the question - ToTimeZone returns local or UTC time zones for BCL, serialization, and IANA zones - Better heuristics for determining whether a CalDateTime is UTC or local - TzId setter now does all the state maintenance for UTC vs local bookkeeping, and all other related properties are get-only - Consistent, ordinal string comparison in GetZone - Truncating parts of DateTimes doesn't suck anymore - Slightly better intellisense documentation - Fixed a broken unit test - Better local vs UTC time zone handling for Unit RRULEs with unit tests - Fixed a bug in the RecurrencePatternEvaluator where tzId wasn't taking into account - MatchTimeZone is less awkward and shorter Issues: #331, #330, #332
rianjs
pushed a commit
that referenced
this issue
Nov 8, 2017
- Use local time zones instead of doing everything in terms of UTC - Set and compare DateTimeKind during serialization and deserialization - Get rid of IsUniversalTime property in IDateTime - IsUtc property is get-only - AsSystemLocal no longer needs to do contortions to answer the question - ToTimeZone returns local or UTC time zones for BCL, serialization, and IANA zones - Better heuristics for determining whether a CalDateTime is UTC or local - TzId setter now does all the state maintenance for UTC vs local bookkeeping, and all other related properties are get-only - Consistent, ordinal string comparison in GetZone - Truncating parts of DateTimes doesn't suck anymore - Slightly better intellisense documentation - Fixed a broken unit test - Better local vs UTC time zone handling for Unit RRULEs with unit tests - Fixed a bug in the RecurrencePatternEvaluator where tzId wasn't taking into account - MatchTimeZone is less awkward and shorter Issues: #331, #330, #332
|
Fixed in nuget version 4.0.0: https://www.nuget.org/packages/Ical.Net/4.0.0 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Right now serialization doesn't handle
DateTimeKind. This makes interop with some libraries (like Telerik's RadSchedule stuff) problematic. If we pay attention to theDateTimeKind, and preserve it during serialization and deserialization, interop will improve, and the library will provide higher-resolution results.The text was updated successfully, but these errors were encountered: