Offset-error #140

nielsk · 2014-12-08T11:42:54Z

I am syncing calendars from iCloud and with loads of events I get the following error:

Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/khal/khalendar/khalendar.py", line 189, in _update_vevent
    ignore_invalid_items=True)
  File "/usr/lib/python2.7/site-packages/khal/khalendar/backend.py", line 269, in update
    ical = icalendar.Event.from_ical(vevent)
  File "/usr/lib/python2.7/site-packages/icalendar/cal.py", line 350, in from_ical
    vals = factory(factory.from_ical(vals))
  File "/usr/lib/python2.7/site-packages/icalendar/prop.py", line 818, in from_ical
    'Offset must be less than 24 hours, was %s' % ical)
ValueError: Offset must be less than 24 hours, was +5328
During `update_vevent` we failed to parse vcard work/someevent.ics with error
"Offset must be less than 24 hours, was +5328",
this means, that event is not available in khal.

For one: the event is not in work/something.ics but in home/something.ics which is strange.
And then there is the content of the .ics which has an Offset of +5328 in one line:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Apple Inc.//Mac OS X 10.8.2//EN
CALSCALE:GREGORIAN
BEGIN:VTIMEZONE
TZID:Europe/Berlin
X-LIC-LOCATION:Europe/Berlin
BEGIN:STANDARD
DTSTART:18930401T000000
RDATE;VALUE=DATE-TIME:18930401T000000
TZNAME:CEST
TZOFFSETFROM:+5328
TZOFFSETTO:+0100
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19160430T230000
RDATE;VALUE=DATE-TIME:19160430T230000
RDATE;VALUE=DATE-TIME:19400401T020000
RDATE;VALUE=DATE-TIME:19430329T020000
RDATE;VALUE=DATE-TIME:19460414T020000
RDATE;VALUE=DATE-TIME:19470406T030000
RDATE;VALUE=DATE-TIME:19480418T020000
RDATE;VALUE=DATE-TIME:19490410T020000
RDATE;VALUE=DATE-TIME:19800406T020000
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:19161001T010000
RDATE;VALUE=DATE-TIME:19161001T010000
RDATE;VALUE=DATE-TIME:19421102T030000
RDATE;VALUE=DATE-TIME:19431004T030000
RDATE;VALUE=DATE-TIME:19441002T030000
RDATE;VALUE=DATE-TIME:19451118T030000
RDATE;VALUE=DATE-TIME:19461007T030000
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19170416T020000
RRULE:FREQ=YEARLY;UNTIL=19180415T010000Z;BYDAY=3MO;BYMONTH=4
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:19170917T030000
RRULE:FREQ=YEARLY;UNTIL=19180916T010000Z;BYDAY=3MO;BYMONTH=9
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19440403T020000
RRULE:FREQ=YEARLY;UNTIL=19450402T010000Z;BYDAY=1MO;BYMONTH=4
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
BEGIN:DAYLIGHT
DTSTART:19450524T020000
RDATE;VALUE=DATE-TIME:19450524T020000
RDATE;VALUE=DATE-TIME:19470511T030000
TZNAME:CEMT
TZOFFSETFROM:+0200
TZOFFSETTO:+0300
END:DAYLIGHT
BEGIN:DAYLIGHT
DTSTART:19450924T030000
RDATE;VALUE=DATE-TIME:19450924T030000
RDATE;VALUE=DATE-TIME:19470629T030000
TZNAME:CEST
TZOFFSETFROM:+0300
TZOFFSETTO:+0200
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:19460101T000000
RDATE;VALUE=DATE-TIME:19460101T000000
RDATE;VALUE=DATE-TIME:19800101T000000
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0100
END:STANDARD
BEGIN:STANDARD
DTSTART:19471005T030000
RRULE:FREQ=YEARLY;UNTIL=19491002T010000Z;BYDAY=1SU;BYMONTH=10
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
BEGIN:STANDARD
DTSTART:19800928T030000
RRULE:FREQ=YEARLY;UNTIL=19950924T010000Z;BYDAY=-1SU;BYMONTH=9
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19810329T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:19961027T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
CREATED:20121120T195219Z
UID:90CBCF8D-DDC8-468D-B140-D2B41B1013E9
DTEND;TZID=Europe/Berlin:20121202T093000
SUMMARY:Some event
DTSTART;TZID=Europe/Berlin:20121202T080000
DTSTAMP:20121120T195239Z
SEQUENCE:6
TRANSP:OPAQUE
BEGIN:VALARM
X-WR-ALARMUID:9CBA1B83-B474-4B6A-8C39-83E55B1E0734
UID:9CBA1B83-B474-4B6A-8C39-83E55B1E0734
TRIGGER;VALUE=DATE-TIME:19760401T005545Z
X-APPLE-DEFAULT-ALARM:TRUE
ACTION:NONE
END:VALARM
END:VEVENT
END:VCALENDAR

The text was updated successfully, but these errors were encountered:

nielsk · 2014-12-08T11:46:42Z

I didn't run again with -v because I see this problem only on the first run of khal

nielsk · 2014-12-08T12:02:13Z

I am using now khal-git from the AUR of Arch and now khal -v results in more information. But this error is from some other file because I don't remember which I used originally as an example. Too many with the error. But the +5328 is in that one as well.

Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/khal/khalendar/khalendar.py", line 170, in _update_vevent
self._dbtool.update(event.raw, href=href, etag=etag)
File "/usr/lib/python2.7/site-packages/khal/khalendar/backend.py", line 241, in update
ical = icalendar.Event.from_ical(vevent)
File "/usr/lib/python2.7/site-packages/icalendar/cal.py", line 350, in from_ical
vals = factory(factory.from_ical(vals))
File "/usr/lib/python2.7/site-packages/icalendar/prop.py", line 818, in from_ical
'Offset must be less than 24 hours, was %s' % ical)
ValueError: Offset must be less than 24 hours, was +5328
error: During update_vevent we failed to parse vcard work/11DDAE95-629D-4524-92CA-4E453B86ACC9.ics with error
error: "Offset must be less than 24 hours, was +5328",
error: this means, that event is not available in khal.
debug: Updating 542A5096-7DC1-41EE-A1E0-584C0683B303.ics because 1418039906.372828484 != 1418039400.432630777
debug: Updating 2CEDFE9B-6C91-4DA9-8DF7-12EBCB8A7ABD.ics because 1418039906.576162100 != 1418039400.212630749
debug: Updating F34E2EF2-1FFF-4325-8752-F6CE7B56221C.ics because 1418039906.556162119 != 1418039400.535964251
debug: Updating 8C0D6814-819E-4517-8D91-3FF4DC4C0D50.ics because 1418039906.432828665 != 1418039400.512630939
debug: Updating 3F3D206F-E972-45CE-9BE5-7890CF4E1D5D.ics because 1418039906.402828693 != 1418039400.319297552
debug: calculating recurrence dates for 3F3D206F-E972-45CE-9BE5-7890CF4E1D5D.ics, this might take some time.
debug: Updating C96895CD-52CC-43C9-93D6-117B25C240E2.ics because 1418039906.636162043 != 1418039400.395964146
debug: Updating D914D88B-3E1D-4EA3-8178-07F98D4CDD02.ics because 1418039906.452828646 != 1418039400.509297609
debug: Updating 10857ACF-E006-412D-A851-9079AA372A44.ics because 1418039906.339495182 != 1418039400.255964041

untitaker · 2014-12-08T12:45:51Z

I brought this issue to collective/icalendar#155 since this is also relevant for icalendar.

geier · 2014-12-08T12:56:52Z

I'll try to have a look ASAP, but probably not before Wednesday, same goes for the other bugs @nielsk just filed.

regebro · 2014-12-08T15:54:29Z

Berlin's local time is 53 minutes and 28 seconds before UTC. However, the above UTF offset is 53 hours and 28 minutes. This is not only incorrect, it's nonsensical. You can't have 2 days and 10 hours as a timezone offset. The correct value should not be +5328, but +005328.

geier · 2014-12-10T17:49:53Z

@nielsk it looks like the only timely fix I can offer you atm is just replacing TZOFFSETFROM:+5328 with TZOFFSETFROM:+0053

nielsk · 2014-12-10T19:37:49Z

@geier which effect would that have?

untitaker · 2014-12-10T19:40:29Z

@nielsk This corrects your broken timezone specification.

geier · 2014-12-10T19:48:35Z

and lets khal/icalendar parse your files. If you are really motivated you could also file that bug at Apple.

nielsk · 2014-12-10T19:55:38Z

sounds good. There do not seem any side effects if you understand you correctly. I will file a bug at Apple if I figured out what produces the wrong offset. But since I do not have an Apple-device anymore and use the iCloud-calendars only because of legacy-reasons (my wive still uses Apple-devices and moving to owncloud made problems in my tests) it might be complicated.

untitaker · 2014-12-10T19:56:26Z

The PRODID is created by the software which originally created the event:

PRODID:-//Apple Inc.//Mac OS X 10.8.2//EN

nielsk · 2014-12-10T19:57:01Z

That would be iCal from a couple of years ago

geier · 2014-12-10T19:57:43Z

Then its probably irrelevant now (I somehow thought 10.8 was the current OS X version).

nielsk · 2014-12-10T19:57:58Z

10.10 is the current one

nielsk · 2014-12-10T19:58:35Z

I also have one with iOS 5.1.1 (we are now at iOS 8)

untitaker · 2014-12-10T19:59:38Z

@nielsk You should try if events created with those OSes still produce invalid events. If no, it's probably enough to fix it manually once.

nielsk · 2014-12-10T20:01:41Z

But I see now OS 10.9 and iOS6 as well. I never had 10.10 installed, so hard to test. I will see what I can do

@untitaker that will be a bit complicated because I have no device right now that is able to run 10.10 (not enough harddisk space on my wives laptop to upgrade) and testing on iOS8 is even harder (a) not enough space for the upgrade, b) I would have to do some set up which might take some time)

untitaker · 2014-12-10T20:03:49Z

Hmm, okay. I wonder though if iCal even correctly interprets the corrected timezone specification. Otherwise a fix would be harder.

nielsk · 2014-12-10T20:07:57Z

I wonder the whole time why the Caldav-tool I am using on Android and Evolution do not have a problem with that offset

untitaker · 2014-12-10T20:08:36Z

Which caldav tool are you using? DAVDroid or CalDAV-Sync?

nielsk · 2014-12-10T20:11:58Z

SmoothSync for Cloud Calendar
But I've just seen that it specializes in syncing with iCloud

untitaker · 2014-12-10T20:14:44Z

@dmfs do you do any timezone-related fixes for iCal?

dmfs · 2014-12-10T20:53:45Z

No, we just don't evaluate the VTIMEZONE object if the TZID is an Olson ID or if it contains one.

Am 10. Dezember 2014 21:14:46 MEZ, schrieb Markus Unterwaditzer [email protected]:

@dmfs do you do any timezone-related fixes for iCal?

Reply to this email directly or view it on GitHub:
#140 (comment)

Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

geier · 2015-02-15T16:30:17Z

I'll close this here, as this is not really a bug in khal (and also because open bug issues make me nervous).

untitaker · 2015-02-15T16:31:21Z

Please reconsider reopening as enhancement, with a label for thirdparty issues.

geier · 2016-04-06T11:52:48Z

Thank you and no rush.

Quoting Niels Kobschätzki (2016-04-06 12:12:36)

@geier I will do so but it will take a bit of time. I can probably test on friday evening or sunday.

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#140 (comment)

nielsk · 2016-04-10T12:30:19Z

@geier The problem still exists. And tbh I don't understand these ics-files since they have several TZOFFSETFROM/TO in them.

An example

VERSION:2.0
PRODID:-//dmfs.org//mimedir.icalendar//EN
BEGIN:VTIMEZONE
TZID:Europe/Berlin
X-LIC-LOCATION:Europe/Berlin
BEGIN:STANDARD
DTSTART:18930401T000000
RDATE;VALUE=DATE-TIME:18930401T000000
TZNAME:CEST
TZOFFSETFROM:+5328
TZOFFSETTO:+0100
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19160430T230000
RDATE;VALUE=DATE-TIME:19160430T230000
RDATE;VALUE=DATE-TIME:19400401T020000
RDATE;VALUE=DATE-TIME:19430329T020000
RDATE;VALUE=DATE-TIME:19460414T020000
RDATE;VALUE=DATE-TIME:19470406T030000
RDATE;VALUE=DATE-TIME:19480418T020000
RDATE;VALUE=DATE-TIME:19490410T020000
RDATE;VALUE=DATE-TIME:19800406T020000
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:19161001T010000
RDATE;VALUE=DATE-TIME:19161001T010000
RDATE;VALUE=DATE-TIME:19421102T030000
RDATE;VALUE=DATE-TIME:19431004T030000
RDATE;VALUE=DATE-TIME:19441002T030000
RDATE;VALUE=DATE-TIME:19451118T030000
RDATE;VALUE=DATE-TIME:19461007T030000
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19170416T020000
RRULE:FREQ=YEARLY;UNTIL=19180415T010000Z;BYDAY=3MO;BYMONTH=4
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:19170917T030000
RRULE:FREQ=YEARLY;UNTIL=19180916T010000Z;BYDAY=3MO;BYMONTH=9
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19440403T020000
RRULE:FREQ=YEARLY;UNTIL=19450402T010000Z;BYDAY=1MO;BYMONTH=4
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
BEGIN:DAYLIGHT
DTSTART:19450524T020000
RDATE;VALUE=DATE-TIME:19450524T020000
RDATE;VALUE=DATE-TIME:19470511T030000
TZNAME:CEMT
TZOFFSETFROM:+0200
TZOFFSETTO:+0300
END:DAYLIGHT
BEGIN:DAYLIGHT
DTSTART:19450924T030000
RDATE;VALUE=DATE-TIME:19450924T030000
RDATE;VALUE=DATE-TIME:19470629T030000
TZNAME:CEST
TZOFFSETFROM:+0300
TZOFFSETTO:+0200
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:19460101T000000
RDATE;VALUE=DATE-TIME:19460101T000000
RDATE;VALUE=DATE-TIME:19800101T000000
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0100
END:STANDARD
BEGIN:STANDARD
DTSTART:19471005T030000
RRULE:FREQ=YEARLY;UNTIL=19491002T010000Z;BYDAY=1SU;BYMONTH=10
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
BEGIN:STANDARD
DTSTART:19800928T030000
RRULE:FREQ=YEARLY;UNTIL=19950924T010000Z;BYDAY=-1SU;BYMONTH=9
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19810329T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:19961027T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=Europe/Berlin:20160406T163000
SUMMARY:Some Event
LOCATION:Some Location
STATUS:CONFIRMED
DTEND;TZID=Europe/Berlin:20160406T173000
LAST-MODIFIED:20160404T141326Z
DTSTAMP:20160404T141326Z
CREATED:20160404T141326Z
UID:fb2c4248-d48a-4137-9050-b172456439d2
TRANSP:OPAQUE
BEGIN:VALARM
TRIGGER;VALUE=DURATION:-PT1H
ACTION:DISPLAY
DESCRIPTION:Default Event Notification
X-WR-ALARMUID:4d8443bb-0332-41eb-b292-3fa649f80b77
END:VALARM
END:VEVENT
END:VCALENDAR

geier · 2016-04-11T12:50:07Z

@nielsk thank you for the feedback, I'll let Apple now.

Regarding the number of TZOFFSETs: there are separate TZOFFSETs for every period with different daylight saving time/standard time transitions, that's why every STANDARD and DAYLIGHT block has its own DTSTART (and RRULE) parameter.

petr-fischer · 2016-06-22T00:34:56Z

Hello I also have this problem with bad offset in events from Mac OS X (iCloud) - offset is +5744.

So khal is ignoring a hundreds of my events - is possible to ignore this timezones in khal event parsing and keep events in view?

I don't want Thunderbid with Lighning gigasoftware, I want just khal in my console :(

BEGIN:STANDARD
DTSTART:18500101T000000
RDATE;VALUE=DATE-TIME:18500101T000000
TZNAME:PMT
TZOFFSETFROM:+5744
TZOFFSETTO:+5744
END:STANDARD
BEGIN:STANDARD
DTSTART:18911001T000000
RDATE;VALUE=DATE-TIME:18911001T000000
TZNAME:CEST
TZOFFSETFROM:+5744
TZOFFSETTO:+0100
END:STANDARD

geier · 2016-06-22T15:32:29Z

If you are not using Apple's server anymore, you can replace all those invalid offsets, e.g. with sed -i. If you are, you could use my icalendar fork (or apply that latest commit by hand). You can also tell the icalendar community that you have this problem, too, which might lead to a speedier resolution collective/icalendar#155 (comment).

geier · 2017-04-14T19:53:57Z

@nielsk in case you are still using icloud, could you perhaps check if this issue is gone? I got an email from apple claiming that they fixed this issue (which last time, they didn't).

oschrenk · 2017-04-15T07:08:01Z

I'm not @nielsk But I also have this error. I tried the sed "trick" once, but the warnings came back.

warning: This event will not be available in khal.
Unknown exception happened.
Traceback (most recent call last):
  File "/usr/local/Cellar/khal/0.9.5/libexec/lib/python3.6/site-packages/khal/khalendar/khalendar.py", line 303, in _update_vevent
    update(event.raw, href=href, etag=etag, calendar=calendar)
  File "/usr/local/Cellar/khal/0.9.5/libexec/lib/python3.6/site-packages/khal/khalendar/backend.py", line 249, in update
    ical = icalendar.Event.from_ical(vevent_str)
  File "/usr/local/Cellar/khal/0.9.5/libexec/lib/python3.6/site-packages/icalendar/cal.py", line 383, in from_ical
    vals = factory(factory.from_ical(vals))
  File "/usr/local/Cellar/khal/0.9.5/libexec/lib/python3.6/site-packages/icalendar/prop.py", line 836, in from_ical
    'Offset must be less than 24 hours, was %s' % ical)
ValueError: Offset must be less than 24 hours, was +5328

untitaker · 2017-04-15T08:52:31Z

Christian, it appears that your fork doesn't differ from upstream.

…

On Sat, Apr 15, 2017 at 12:08:02AM -0700, Oliver Schrenk wrote: I'm not @nielsk But I also have this error. I tried the sed "trick" once, but the warnings came back. ``` warning: This event will not be available in khal. Unknown exception happened. Traceback (most recent call last): File "/usr/local/Cellar/khal/0.9.5/libexec/lib/python3.6/site-packages/khal/khalendar/khalendar.py", line 303, in _update_vevent update(event.raw, href=href, etag=etag, calendar=calendar) File "/usr/local/Cellar/khal/0.9.5/libexec/lib/python3.6/site-packages/khal/khalendar/backend.py", line 249, in update ical = icalendar.Event.from_ical(vevent_str) File "/usr/local/Cellar/khal/0.9.5/libexec/lib/python3.6/site-packages/icalendar/cal.py", line 383, in from_ical vals = factory(factory.from_ical(vals)) File "/usr/local/Cellar/khal/0.9.5/libexec/lib/python3.6/site-packages/icalendar/prop.py", line 836, in from_ical 'Offset must be less than 24 hours, was %s' % ical) ValueError: Offset must be less than 24 hours, was +5328 ``` -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #140 (comment)

petr-fischer · 2017-04-15T16:07:32Z

@geier The problem with bad offsets from Apple servers still exists. When I create event via iCloud WEB site, this is in event:

BEGIN:VTIMEZONE
TZID:Europe/Prague
X-LIC-LOCATION:Europe/Prague
BEGIN:STANDARD
DTSTART:18500101T000000
RDATE;VALUE=DATE-TIME:18500101T000000
TZNAME:PMT
TZOFFSETFROM:+5744                                                                                                                                                                                                  
TZOFFSETTO:+5744
END:STANDARD
...

geier · 2017-04-16T13:10:22Z

@untitaker I deleted my fork some time ago and re-forked, forgot about this issue. But this would be one of the things I really would like to fix in icalendar, perhaps with a mode=[strict|loose] flag.

@petr-fischer thanks for checking!

geier · 2017-07-19T12:29:49Z

For people looking for a fork of icalendar that ignore this problem, try this branch of icalendar.

When a (nonsensical) TZOFFSET > 24h is encountered, print a warning but do not abort. This commit also creates a new method for icalendar.Calendar creation, which deals with the above mentioned TZOFFSETs. It should always be used for icalendar.Calendar creation. fixes #140

geier · 2017-10-09T15:13:20Z

As the latest release of icalendar allows to ignore TZOFFSETs > 24h, we can now finally import those ics files (a warning is printed though).

oschrenk · 2017-10-09T15:57:15Z

Awesome! Is there a way to suppress this type of warning?

geier · 2017-10-10T07:59:41Z

@oschrenk you could silence ALL warnings with khal -v ERROR, but that really isn't a great idea.
Perhaps we need a new config variable to suppress this specific error?

Feel free to open an issue about it.

petr-fischer · 2017-11-08T11:17:00Z

Hello, do i really need to install a fork of iCalendar? Will be this fix available in official icalendar pip package? I installed khal on the FreeBSD in my home directory with this:

./.local/bin/pip install -U --user khal

Actual versions:

khal (0.9.8)      - A standards based terminal calendar
  INSTALLED: 0.9.8 (latest)
icalendar (3.12)                           - iCalendar parser/generator
  INSTALLED: 3.12 (latest)

geier · 2017-11-08T14:17:22Z

no, there is no need to install a fork of icalendar anymore, releases of icalendar >= 3.11.7 contain a switch that allows to ignore those invalid offsets, but only the unreleased version of khal makes use of that. If you "upgrade" to the master branch you should be good, otherwise you'll need to wait for a release.

petr-fischer · 2018-10-11T19:07:44Z

@geier - Hello! Do you plan to include fix for "offset" issues to the official version release (which is taken over by FreeBSD [and other] port maintainers)?

geier · 2018-10-11T20:19:29Z

Yes, I plan to and rather shortly.

untitaker added the type: bug label Dec 8, 2014

untitaker mentioned this issue Dec 8, 2014

Offsets larger than 24h? collective/icalendar#155

Closed

geier closed this as completed Feb 15, 2015

geier added type: enhancement and removed type: bug labels Feb 15, 2015

geier marked this as a duplicate of #684 Jul 19, 2017

geier mentioned this issue Jul 19, 2017

Offset problem in ikhal #684

Closed

geier added type: bug and removed type: enhancement labels Aug 28, 2017

geier mentioned this issue Oct 8, 2017

Read files with TZOFFSET > 24 and print warning #724

Merged

geier added the in progress label Oct 8, 2017

ghost assigned geier Oct 8, 2017

geier closed this as completed in #724 Oct 8, 2017

geier removed the in progress label Oct 8, 2017

Offset-error #140

Offset-error #140

Comments

nielsk commented Dec 8, 2014

nielsk commented Dec 8, 2014

Uh oh!

nielsk commented Dec 8, 2014

Uh oh!

untitaker commented Dec 8, 2014

Uh oh!

geier commented Dec 8, 2014

Uh oh!

regebro commented Dec 8, 2014

Uh oh!

geier commented Dec 10, 2014

Uh oh!

nielsk commented Dec 10, 2014

Uh oh!

untitaker commented Dec 10, 2014

Uh oh!

geier commented Dec 10, 2014

Uh oh!

nielsk commented Dec 10, 2014

Uh oh!

untitaker commented Dec 10, 2014

Uh oh!

nielsk commented Dec 10, 2014

Uh oh!

geier commented Dec 10, 2014

Uh oh!

nielsk commented Dec 10, 2014

Uh oh!

nielsk commented Dec 10, 2014

Uh oh!

untitaker commented Dec 10, 2014

Uh oh!

nielsk commented Dec 10, 2014

Uh oh!

untitaker commented Dec 10, 2014

Uh oh!

nielsk commented Dec 10, 2014

Uh oh!

untitaker commented Dec 10, 2014

Uh oh!

nielsk commented Dec 10, 2014

Uh oh!

untitaker commented Dec 10, 2014

Uh oh!

dmfs commented Dec 10, 2014

Uh oh!

geier commented Feb 15, 2015

Uh oh!

untitaker commented Feb 15, 2015

Uh oh!

geier commented Apr 6, 2016

Uh oh!

nielsk commented Apr 10, 2016

Uh oh!

geier commented Apr 11, 2016

Uh oh!

petr-fischer commented Jun 22, 2016

Uh oh!

geier commented Jun 22, 2016

Uh oh!

geier commented Apr 14, 2017

Uh oh!

oschrenk commented Apr 15, 2017

Uh oh!

untitaker commented Apr 15, 2017 via email

Uh oh!

petr-fischer commented Apr 15, 2017

Uh oh!

geier commented Apr 16, 2017

Uh oh!

geier commented Jul 19, 2017

Uh oh!

geier commented Oct 9, 2017

Uh oh!

oschrenk commented Oct 9, 2017

Uh oh!