GroupWise 约会的日期不正确，> 50 年后
从 GroupWise 获取约会列表时，检索到的约会对象中的某些日期与 GroupWise 中的值不匹配，实际上它们是 50 多年以后的日期。 例如，在以下方法中，我查找从 2000 年 1 月 1 日午夜或之后开始，到 2010 年 12 月 31 日 23:59:59 或之前结束的约会：-
public List<Appointment2> GetGroupWiseAppointments()
{
Application2Class gwApp = new Application2Class();
Account gwAccount = gwApp.Login(Type.Missing, Type.Missing, LoginConstants.egwPromptIfNeeded, Type.Missing, Type.Missing);
Folder gwCalendar = gwAccount.Calendar;
List<Appointment2> appointments = new List<Appointment2>();
MessageList gwAppointments = gwCalendar.Messages.Find("( APPOINTMENT AND BOX_TYPE = INCOMING AND START_DATE >= 2000/1/1 AT 0:0:0 AND DUEEND_DATE <= 2010/12/31 AT 23:59:59 )");
foreach(Appointment2 gwAppointment in gwAppointments)
{
appointments.Add(gwAppointment);
}
}
在我的测试数据中，所有约会的日期都在今天的 2 周内，但返回的对象是未来58年3个月1天13小时16分钟。 更奇怪的是，这并不是每次你取回它们时都会发生！
以前有人经历过这种情况并找到解决方案吗？
When fetching a list of appointments from GroupWise some of the dates in the retrieved appointment objects do not match the values in GroupWise, in fact they are more than 50 years in the future. For instance in the following method I look for appointments starting on or after 1st Jan 2000 midnight and ending on or before 31st December 2010 23:59:59:-
public List<Appointment2> GetGroupWiseAppointments()
{
Application2Class gwApp = new Application2Class();
Account gwAccount = gwApp.Login(Type.Missing, Type.Missing, LoginConstants.egwPromptIfNeeded, Type.Missing, Type.Missing);
Folder gwCalendar = gwAccount.Calendar;
List<Appointment2> appointments = new List<Appointment2>();
MessageList gwAppointments = gwCalendar.Messages.Find("( APPOINTMENT AND BOX_TYPE = INCOMING AND START_DATE >= 2000/1/1 AT 0:0:0 AND DUEEND_DATE <= 2010/12/31 AT 23:59:59 )");
foreach(Appointment2 gwAppointment in gwAppointments)
{
appointments.Add(gwAppointment);
}
}
In my test data all of the appointments are dated within 2 weeks of today but the returned objects are 58 years 3 months 1 day 13 hours and 16 minutes in the future. What is more strange is that this doesn't happen every time you retrieve them!
Has anyone experienced this before and have they found a solution to it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我已经找到了解决这个问题的方法。 我不太清楚为什么，但是当将列表中的数据加载到我的数据类型中时，会导致列表中的数据损坏。 通过将其更改为加载到 POCO 中，问题就消失了。
I have found a solution to this issue. I'm not quite sure why but when loading the data from the List into my data type was causing the data still in the list to get corrupted. By changing it to load into a POCO the issue went away.
您是否遇到 32 位时间问题？ 通常 CTIME，32 位时间，自 1970 年 1 月 1 日午夜加一秒（GMT）开始计算为秒。 根据它的实现方式，它可能是一个符号整数，这意味着您可以引用 1970 年之前的日期，或者它可能不被视为有符号，在这种情况下，它可以进入 32 位空间的后半部分（上半部分） 20 亿）。
CTIME 已签署，将于 2037/2038 年到期（2038 年 2 月？类似之类的）。 CTIME 未签名，原则上应该还有 68 年的有效期？ （2038-1970 = 68 年）。
有没有可能你已经晚了 68 年，而不是 58 年，并且这是某个地方的 CTIME 签名/无符号转换问题？
Are you running into an issue of 32 bit time? Usually CTIME, 32 bit time, is counted as seconds since Jan 1, 1970, mignight plus one second, GMT. Depending on how it is implemented, it might be a sign integer, which means you can refer to dates before 1970, or it might not be considered as signed, in which case it can go into the second half of a 32 bit space (upper 2 billion).
CTIME signed, runs out in 2037/2038 (Feb 2038? Something like that). CTIME unsigned, in principle should be good for another 68 years? (2038-1970 = 68 years).
Is it possible you are off by 68 years, not 58 years, and that it is a CTIME signed/unsigned conversion somewhere problem?