Skip to content
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

Closed
pomoika opened this issue Nov 2, 2017 · 7 comments
Closed

Comments

@pomoika
Copy link

pomoika commented Nov 2, 2017

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.

@rianjs
Copy link
Owner

rianjs commented Nov 2, 2017

Could you provide a code example demonstrating the problem?

@pomoika
Copy link
Author

pomoika commented Nov 2, 2017

Here is a simple sample:

            const string source = @"
BEGIN:VCALENDAR
PRODID:-//github.com/rianjs/ical.net//NONSGML ical.net 2.2//EN
VERSION:2.0
BEGIN:VEVENT
DTEND;TZID=Central Standard Time:20171102T093000
DTSTART;TZID=Central Standard Time:20171102T090000
RRULE:FREQ=WEEKLY;COUNT=4;BYDAY=MO
SEQUENCE:0
END:VEVENT
END:VCALENDAR";
            ICalendar cal = Calendar.LoadFromStream(new StringReader(source)).First();
            IDateTime start = cal.Events[0].Start;
            Console.WriteLine(start.ToString());
            IDateTime eastern = start.ToTimeZone("Eastern Standard Time");
            Console.WriteLine(eastern.ToString());

11/2/2017 9:00:00 Central Standard Time
11/2/2017 14:00:00 UTC

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
@rianjs
Copy link
Owner

rianjs commented Nov 13, 2017

Fixed in nuget version 4.0.0: https://www.nuget.org/packages/Ical.Net/4.0.0

@rianjs rianjs closed this as completed Nov 13, 2017
@afterlogic-support
Copy link

Those who are not on .NET Core are out of luck to get this fix?

@rianjs
Copy link
Owner

rianjs commented Feb 10, 2018

v4 is .NetStandard 1.3, which means you can use it with .NET 4.6 and higher.

@afterlogic-support
Copy link

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!

@rianjs
Copy link
Owner

rianjs commented Feb 10, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants