在iOS设置应用中，有一个名为“时区支持”的设置（设置＆gt;邮件，通讯录，日历＆gt;时区支持）。如果此设置为关闭，则表示没有问题。此外，如果此设置为开启，但时区支持（TZS）时区设置为当前值systemTimeZone，则也没有问题。 唯一出现问题的是设置为开启且TZS时区设置为systemTimeZone 以外的时区。
在最后一种情况下，eventsMatchingPredicate:方法返回的数组（在EKEventStore类的实例上）可预测地被截断。给定对日期范围内的所有事件的查询，EKEventStore的实例无法返回介于查询范围的开头和TZS时区的第一个午夜之间的任何事件。
为了提供一个示例，为了检索2013年3月18日的所有事件，我们会在{{1}的3/18/2013 12AM和3/19/2013 12AM之间发出所有事件的查询。 }。假设systemTimeZone是PDT，这将导致查询2013年3月18日格林尼治标准时间上午7点到格林威治标准时间3月19日上午7点之间的所有事件（因为PDT是格林威治标准时间--7小时）。此查询适用于TZS OFF，以及TZS ON并设置为PDT。但是，如果TZS为ON并设置为EDT，则查询范围的开始和EDT中的第一个午夜之间的所有事件都将从结果数组中丢失。由于EDT是GMT - 4小时，因此在查询范围内的EDT第一个午夜是格林尼治标准时间3月19日凌晨4点。 2013年3月18日格林威治标准时间7AM和格林威治标准时间3/19/2013之间的所有事件都将丢失，结果数组仅包含2013年3月19日格林威治标准时间4点至2013年3月19日格林威治标准时间7点30分之间的事件。
这个结果是100％可预测的，无论是在模拟器中还是在物理iOS设备上（我尝试过的任何TZS时区）。我在iOS 6和iOS 6.1上进行了测试，没有明显的行为差异。有什么理由让我错过了为什么这可能是预期的API行为？此外，尽管进行了大量搜索，但似乎没有公共（甚至是私有）API允许开发人员确定TZS是打开还是关闭，更不用说用户设置的任何时区 - 这使得很难想到一个很好的解决方法...（显然，你可以通过增加每个查询的范围来确保你不会错过任何事件，这样它就会在任何可能的TZS时区中包含午夜。然后，你可以过滤掉无关的事件在代码中。但是，出于显而易见的原因，我想避免像这样的hacky方法，除非作为最后的手段。）
答案 0 :(得分：1)
我遇到了类似的问题，即结果中未返回给定NSDate范围第一天的某些事件。我发现[EKEventStore eventsMatchingPredicate]似乎受到默认时区的影响。这种解决方法最终帮助了我：
NSTimeZone *savedTimeZone = [NSTimeZone defaultTimeZone];
[NSTimeZone setDefaultTimeZone:[NSTimeZone timeZoneForSecondsFromGMT:0]];
NSPredicate *predicate = [eventStore predicateForEventsWithStartDate:startDate endDate:endDate calendars:calendars];
[NSTimeZone setDefaultTimeZone:savedTimeZone];
NSArray *events = [eventStore eventsMatchingPredicate:predicate];
我希望希望这也有助于您的具体情况（在我的情况下，用户的日期/时间区域与应用程序中的默认时区不同，在您的情况下，日历时间支持已启用，但它是可能是'predicateForEventsWithStartDate'）
的相同情况在我看来，这是[EKEventStore eventsMatchingPredicate]中的错误或设计缺陷，因为给定的NSDates已经是“时区少”，因为它们表示时间点，没有时区相关。