2009-01-15 5 views
1

J'ai une ancienne application basée sur C++ qui horodate le trafic réseau entrant en utilisant la fonction CRT _ftime(). La fonction _ftime() renvoie une structure _timeb, qui a une implémentation 32 bits et 64 bits. Nous utilisons la mise en œuvre de 32 bits, ce qui ressemble à ceci:Convert System :: DateTime en _timeb

struct _timeb { 
    long time;    // 4 bytes 
    unsigned short millitm; // 2 bytes 
    short timezone;   // 2 bytes 
    short dstflag;   // 2 bytes 
}; 

De la documentation MSDN, voici comment chaque champ est interprété:

  • dstflag - non nulle si l'heure d'été est actuellement en vigueur pour la zone heure locale (voir _tzset pour une explication de la façon dont l'heure d'été est déterminée.)
  • millitm - fraction de seconde en millisecondes
  • temps - heure en secondes depuis minuit (00:00:00), le 1er janvier 1970, heure universelle coordonnée (UTC).
  • fuseau horaire - différence en minutes, se déplaçant vers l'ouest, entre l'heure UTC et l'heure locale. La valeur de timezone est définie à partir de la valeur de la variable globale _timezone (voir _tzset).

Je suis re-travail de la partie du code qui fait la timestamping utiliser C# .NET 3.5 dans . Les horodatages sont maintenant générés à l'aide de la structure System.DateTime, mais j'ai toujours besoin de les convertir à la structure _timeb afin que le code C++ hérité puisse fonctionner sur eux. Voici comment je fais cela dans ma bibliothèque gérée pont C++:

DateTime dateTime = DateTime::UtcNow; 
DateTime baseTime(1970, 1, 1, 0, 0, 0, DateTimeKind::Utc); 
TimeSpan delta = dateTime - baseTime; 

_timeb timestamp; 
timestamp.time  = delta.TotalSeconds; 
timestamp.millitm = dateTime.Millisecond; 
timestamp.dstflag = TimeZoneInfo::Local->IsDaylightSavingTime(dateTime) ? 1 : 0; 
timestamp.timezone = TimeZoneInfo::Local->BaseUtcOffset.TotalMinutes * -1; 

D'après ce que je peux dire, cela semble reconstruire la structure _timeb comme si je l'avais appelé _ftime() directement, et ce qui est bon. Le fait est que les timestamps sont un élément essentiel de notre application, donc cela doit être correct.

Ma question est double.

  1. Mon algorithme est-il défectueux? Est-ce que quelqu'un voit quelque chose d'évident que j'ai manqué? Y a-t-il des conditions aux limites où cela ne fonctionnera pas?
  2. Existe-t-il une meilleure façon de faire la conversion? Est-ce que .NET a un moyen de le faire d'une manière plus directe?
+0

comment cette réponse résout-elle votre problème? hmm – Muj

Répondre

0

Vous êtes au courant du problème Y2K38? Je suppose que vous avez vérifié le signe de .timezone. Évitez l'ingéniosité d'utiliser dateTime.Millisecond, qui confond juste le prochain type. Ça a l'air bon sinon.

+1

Pas si inquiet à propos de Y2K38. :) Que voulez-vous dire par rapport à l'ingéniosité de dateTime.Millisecond? –