Назначения GroupWise неверно датированы,> через 50 лет

Question

Назначения GroupWise неверно датированы,> через 50 лет

2

При получении списка назначений из GroupWise некоторые из дат в найденных объектах назначения не соответствуют значениям в GroupWise, на самом деле они более 50 лет в будущем. Например, в следующем методе я ищу встречи, начинающиеся с 1 января 2000 года или после них, и заканчивающиеся до или до 31 декабря 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);
    }
}

В моих тестовых данных все встречи датируются в течение 2 недель, но возвращенные объекты составляют 58 лет 3 месяца 1 день 13 часов и 16 минут в будущем. Более странно то, что это не происходит каждый раз, когда вы их извлекаете!

Кто-нибудь испытал это раньше и нашел ли он решение?

Richard Hopton 08 июль 2009, в 18:18

Источник

0

Хорошо - сюжет утолщается. Разница между фактической датой и отчетной датой обычно одинакова для сеанса, но часто изменяется - до сих пор различия были (в днях до 5 дп) 21245,55278, 16378,13727 и 6290,71832.
Richard Hopton 09 июль 2009, в 11:53

Теги:

c#

api

novell

groupwise

2 ответа

Ещё вопросы

Хорошо - сюжет утолщается. Разница между фактической датой и отчетной датой обычно одинакова для сеанса, но часто изменяется - до сих пор различия были (в днях до 5 дп) 21245,55278, 16378,13727 и 6290,71832.

Richard Hopton · Answer 1 · 2009-07-30T08-08-00.000Z

Я нашел решение этой проблемы. Я не совсем уверен, почему, но при загрузке данных из списка в мой тип данных происходит повреждение данных, находящихся в списке. Изменив его для загрузки в POCO, проблема исчезла.

geoffc · Answer 2 · 2009-07-08T15-30-00.000Z

Вы сталкиваетесь с проблемой 32-битного времени? Обычно CTIME, 32-битное время, отсчитывается как секунды с 1 января 1970 года, мигающий плюс одна секунда, GMT. В зависимости от того, как он реализован, это может быть знак целого числа, что означает, что вы можете ссылаться на даты до 1970 года, или он может не считаться подписанным, и в этом случае он может перейти во вторую половину 32-битного пространства (верхний 2000000000).

CTIME подписан, заканчивается в 2037/2038 (февраль 2038? Что-то вроде этого). CTIME неподписанный, в принципе должен быть хорош еще на 68 лет? (2038-1970 = 68 лет).

Возможно ли, что вы отключены на 68 лет, а не 58 лет, и что это проблема CTIME, подписанная/без знака, где-то проблема?