-
Notifications
You must be signed in to change notification settings - Fork 232
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CalDateTime.ToTimeZone produces UTC time instead of target time zone #330
Comments
Could you provide a code example demonstrating the problem? |
Here is a simple sample:
11/2/2017 9:00:00 Central Standard Time |
- 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
- 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
- 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 |
Those who are not on .NET Core are out of luck to get this fix? |
v4 is .NetStandard 1.3, which means you can use it with .NET 4.6 and higher. |
My target is .NET 4.5. Anyway, I took the fixed code from net-core branch and made it work as a separate util method (so I'm not using ToTimeZone at all now). Can live with that for now. Thanks! |
In a perfect world, I would support .NET 4.5+, but there were reasons (that I can't recall now) why .NetStandard < 1.3 wouldn't work. |
It looks like CalDateTime.ToTimeZone always creates CalDateTime in UTC even though internal conversion between source and destination time zones has been done properly (e.g. from "Central Standard Time" to "Eastern Standard Time"). The result is represented in UTC, whereas I would expect it in desired time zone. The same issue occurs in DateUtil.MatchTimeZone method.
The text was updated successfully, but these errors were encountered: