2009-07-08 4 views
2

Lors de la récupération d'une liste de rendez-vous à partir de GroupWise, certaines dates des objets de rendez-vous récupérés ne correspondent pas aux valeurs de GroupWise, en fait, elles sont plus de 50 ans . Par exemple, dans la méthode suivante je cherche des rendez-vous ouverts à compter du 1 janvier 2000 à minuit et se terminant le ou avant le 31 Décembre 2010 23: 59: 59: -Les rendez-vous GroupWise sont incorrectement datés,> 50 ans dans le futur

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); 
    } 
} 

Dans mes données de test toutes les nominations sont datées dans les 2 semaines d'aujourd'hui mais les objets retournés sont 58 ans 3 mois 1 jour 13 heures et 16 minutes dans le futur. Ce qui est plus étrange, c'est que cela n'arrive pas chaque fois que vous les récupérez!

Quelqu'un at-il déjà vécu cela et a-t-il trouvé une solution?

+0

Ok - l'intrigue s'épaissit. La différence entre la date réelle et la date déclarée est normalement la même pour une session, mais change souvent - jusqu'à présent, les différences ont été (en jours à 5dp) 21245.55278, 16378.13727 et 6290.71832 –

Répondre

1

Vous rencontrez un problème de temps de 32 bits? Habituellement, CTIME, temps 32 bits, est compté en secondes depuis le 1er janvier 1970, mignight plus une seconde, GMT. Selon la façon dont il est implémenté, il peut s'agir d'un signe entier, ce qui signifie que vous pouvez vous référer à des dates antérieures à 1970 ou ne pas être considérées comme signées, auquel cas il peut entrer dans la seconde moitié d'un espace de 32 bits. 2 milliards). CTIME signé, épuisé en 2037/2038 (février 2038? Quelque chose comme ça)

CTIME non signé, en principe devrait être bon pour encore 68 ans? (2038-1970 = 68 ans).

Est-il possible que vous soyez déconnecté de 68 ans, et non de 58 ans, et qu'il s'agisse d'un problème de conversion CTIME signé/non signé?

2

J'ai trouvé une solution à ce problème. Je ne sais pas trop pourquoi, mais en chargeant les données de la liste dans mon type de données, les données de la liste étaient corrompues. En le changeant pour charger dans un POCO le problème est parti.

Questions connexes