tikitu
commented
7 years ago Welp, the answer might just be "yes that's a terrible idea". At least, I think it will not solve the original problem: that round-tripping a DATE-TIME property through XbICalendar loses timezone information. The new wrinkle I've dug up is: NSTimeZone itself isn't a tight match for icaltimezone, with conversions in both directions potentially going wrong. (An icaltimezone might use a timezone name that's defined locally in the calendar file, which NSTimeZone won't recognise. In that case we can't make a corresponding NSTimeZone object without translating all the internal details of the icaltimezone, which doesn't sound fun. I think something similar can happen going the other direction; I'm also having trouble loading builtin (Olson) timezones in libical but that might just be a setup mistake on my part.)
Since NSDateComponents uses NSTimeZone for its timezone info, that means a round-trip is not guaranteed.
In fact the only way I see to guarantee the roundtrip is to keep the TZID string around somewhere. Which means a custom type, and I start wondering if it's all worth my while (compared to a more direct Swift wrapper around the types-and-operations defined in libical).
ahalls
Hi folks,
I'm wondering why XbICalendar uses NSDate to represent DATE-TIME and DATE properties, and whether NSDateComponents might be a better choice. In particular:
NSDateComponentsinstance with hours/minutes/seconds unset is an apt representation for a "calendar date" (DATE).NSDateComponentsinstance with an explicit timezone is a better representation for a DATE-TIME, since the timezone component can be important for date-time arithmetic.I'm not aware of any issues caused by the first point, it just "fits". The second, more important, point is what got me started on this. I'm working on a bug over in my fork which makes RRULE properties misbehave across a DST boundary: https://github.com/minddistrict/XbICalendar/tree/preserve-timezone-strings
The root cause is that when an DTSTART property makes a round-trip from
icalpropertytoXbICPropertyand back toicalpropertyit loses the original timezone, becauseXbICPropertyrepresents it asNSDatewhich forgets its timezone information. (This makes sense. An NSDate represents an instant in time: two NSDate objects created from different timezones but identifying the same instant should compare equal, which implies forgetting the originating timezone.)So I'm thinking that the "right" fix for that bug would be to convert to using NSDateComponents for DTSTART, which implies using them for all DATE-TIME properties, and then I might as well go ahead and convert DATE properties too.
My question for y'all is: am I missing some design considerations that make this a terrible idea? And if not, how do you rate the chances of landing a PR with these changes? It's a change to the external API of the library, so needs some release management.