Bonjour à tous
 
J'utilise csvde.exe pour exporter absolument toutes les infos de mon domaine, dans le but de pouvoir scripter par la suite des mises à jour automatiques des Users de mon domaine...
 
Mais chaque chose en son temps, je m'occupe d'abord d'analyser en quoi consiste une ligne du CSV exporté grâce à cette commande :  

 
Je comprends plus ou moins les éléments, mais je cale grave sur la fin de validité du compte, celle que l'on définit dans Active Directory avec Utilisateur -> Propriétés -> Compte -> Date d'expiration.
 
Voici en premier lieu une ligne CSV d'un utilisateur bidon de mon domaine, sans expiration de compte (je mets des retours chariots pour faciliter l'affichage ici mais il s'agit bien d'une seule ligne CSV):  
 

 
 
Je modifie la date de validité du compte et je la définis au 1/11/2005. Je refais une exportation CSV et la valeur en gras dans la ligne ci-dessus passe à  
127753596000000000.
 
Je change ensuite la date et la définis au 4/11/2005, et la valeur passe à  
127756188000000000.
 
En soustrayant les deux valeurs en ignorant les sept derniers 0 (et pourquoi ?), on obtient 259200, ce qui correspond exactement au nombre de secondes contenues dans 3 jours ; l'écart correspond donc.
 
Mais voilà le problème :  
 
Je voudrais pouvoir définir une date précise. Et ces valeurs ne sont visiblement pas des "time stamp" traditionnels, dans la mesure où le 1/11/2005 à 0h00:00 GMT = 1130803200 t_stamp.
 
La question : QUELLE est cette unité made in Microsoft ?
 
*EDIT* : quelques typos

Trouvé la réponse (ça a été dur) !  
 
http://msdn.microsoft.com/library/ [...] letime.asp
 
La date est donc stockée sur un entier signé de 64 bits qui représente le nombre de dixièmes de microsecondes (= paquets de 100 nanosecondes) écoulées depuis le 1-1-1601 à 0h0:0
 
Pour ceux que ça intéresse, explication de ma démarche geekeuse pour trouver ça :  
 
Je me suis douté que le chiffre en gras ci-dessus était une max_value quelconque, et c'est effectivement le cas :  
9223372036854775807 = (2 exposant 63) -1. Probablement parce que le 64ème bit qui sert à écrire ce nombre quelque part, sert au signe.
 
J'ai trouvé un outil de calcul de la date à partir du time_stamp à l'adresse suivante : http://www.csgnetwork.com/unixds2timecalc.html
 
J'entre 127753596000000000 et je trouve le 1/11/2374... à 23h mais cette marge est probablement due à quelques erreurs au niveaux des années bissextiles.. n'empêche que nous voilà à 369 ans presque jour pour jour de la date que je cherche ... plus qu'à soustraire cela à 1970 (date de début du time_stamp UNIX traditionnel ...) et hop on tombe sur 1601 ... NETTEMENT plus facile de rechercher sur Google avec ça