the problem is the caused by the data in the source ics file (you said produce by Events Manager plugin). The DTSTAMP fields don't look correct. In particular the one my plugin is complaining about is rather 'wrong'.
SUMMARY:Labor Day - School Closed
The source ics file has a smattering of weird DTSTAMP dates that cannot be correct 1969, 1970 etc - I doubt your ics file was last generated or events last modified around the birth of the internet!
Trying to make a DATETIME object out of a bad datestring would normally cause a fatal error, except my plugin has code to trap the exception, highlight it and then 'continue'. Otherwise you wouldn't know there was a problem or a missed event.
So.... what to do?
"event manager" should fix their DTSTAMPS....
What should my plugin do with badly formed dates? Should it "fail silently"?
Obviously DTSTART and DTEND must be correct else events won't make sense or will be skipped. But what about DTSTAMP ? how 'important' is it to have this correct?
I did some web searching, and some opinions are that it should be reasonably accurate (some references below), and some old notes that ms outlook requires DTSTAMP (maybe older versions?)
Interestingly, Google seems to accept the ics file without complaint, so possibly it is ignoring the bad DTSTAMP.
Some posts indicate possible problems with synchronisation after event modifications if DTSTAMPs not available or not correct.
So in my opinion,
1) a correctly formed DTSTAMP is probably worth having to ensure consistent use across all calendar applications.
2) there is low risk in allowing a dud DTSTAMP through in my plugin as the plugin is only displaying (not synchronising).
Sooooo.....The next update will report such data errors a lot more discretely, possibly only to logged-in admin.
The DTSTAMP is defined by RFC 5545 as
...the date and time that the instance of the iCalendar object was created. In the case of an iCalendar object that doesn't specify a "METHOD" property, this property specifies the date and time that the information associated with the calendar component was last revised in the calendar store.
This is interpreted in various ways. Could be important in resolving clashes on UID and SEQUENCE when there are updates.
"Message Sequencing" says if there are multiple
messages that match on UID and SEQUENCE, then the one with the later
Synchronization problem with DTSTAMP and LAST-MODIFIED: