Valeur DateTime Tick

Bonjour à tous,

Je rencontre depuis quelques temps un soucis sur un service Windows permettant de télécharger et importer toutes les nuits des fichiers XML en base de données, jusque là rien de bien compliqué...

Pour savoir si un fichier doit ou non être télécharger, on regarde si la date de modification du fichier distant (sur le FTP) est plus récente que celle de notre fichier local, rien de bien compliqué non plus me direz vous. Pour comparer les dates, on se sert du tick.
En règle générale, les mises à jour sur le FTP se font aux alentours de 22h et le service se lance à 1h du matin (le lendemain donc).

Cependant, j'ai un soucis lorsque des fichiers sont mis à jour côté FTP, ils ne le sont que 2 jours plus tard chez nous.
Par exemple, une mise à jour côté FTP a lieu un lundi à 22h, le service qui tourne le mardi à 1h ne va pas détecter de modification et les mises à jours ne se feront que le mercredi à 1h.

Pour identifier la source du problème, j'ai donc loguer les ticks de dernière modification et stupeur voici ce que j'obtiens :
- Fichier local, dernière modification : 20/01/2012 02h00 -> tick = 634626180209853972
- Fichier distant, dernière modification : 24/04/2012 22h03 -> tick = 634625654400000000

On remarque bien que la valeur du tick du fichier local est plus grande alors que la dernière modification est antérieure à celle du fichier distant...

Et la question est...Pourquoi ?:aie:

(Si vous avez une meilleure solution que le tick, ce n'est pas moi qui ai mit cette méthode en place, je suis ouvert :))

pourquoi ne pas comparer les dates directement ?

Parce que c'était fait comme ça avant, que l'on avait pas identifié de problème...

C'est une solution certes, mais ces valeurs bizarres me chiffonnent !!

je veux bien croire :D
tu as bien vérifié à l'exécution que c'est bien les dates que tu donnes qui sont utilisées par le code

sinon quand je dois comparer 2 dates, moi je compare les 2 dates ... il ne me vient pas à l'idée de les transformer :aie:

Par curiosité, je viens de faire le test avec ces deux dates et j'obtiens un résultat cohérent...

N'y a-t-il pas une instruction qui modifierait ces dates avant d'en extraire les ticks ? Ne serait-ce pas simplement inversé ?

Bref, avec du code, ce serait mieux ^^

Ouais il ne me serait pas venu à l'idée de les transformer non plus...mais bon.

Vous voulez du code :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

'FTP date bug fix : the year is always the current year 'consequence : on year change all the files are considered updated Dim correctedRemoteDate As DateTime = remoteFile.LastModified If remoteFile.LastModified > DateTime.Now Then correctedRemoteDate = correctedRemoteDate.AddYears(-1) End If 'Checking if remote file has been modified since the last update) If correctedRemoteDate.Ticks > localFile.LastWriteTime.Ticks Then Me.modifiedProducts.Add(Me.FoProductsDirectory & "\" & remoteFile.Name, remoteFile) End If

---

RemoteFile est de type FTPFile, définit dans une librairie externe...la date est peut être dans une culture différente.
Je vais reloguer les dates cette nuit pour être sur, mais ce que je comprends pas pourquoi le tick fonctionne deux jours après et pas le lendemain...

il doit y avoir un bug dans ta dll qui récupère la date, un bug aussi gros ne peut pas être dans le framework

soit ca ne récupère pas la bonne date, soit ca la transforme mal en datetime à partir du string
une variable datetime en .net n'as pas de culture, c'est une représentation binaire

Ouais je me disais bien aussi :roll:

Merci bien pour vos réponses.

Surtout qu'apparemment, ce n'est pas comme si la ddl était bug free vu que vous corrigez déjà un truc manuellement au niveau de l'année :aie:

Ouais je sais bien :P

Mais je trouve bizarre qu'à j+1 il ne voit pas de modif' et à j+2 il en voit...

C'est le problème des ticks qui est bizarre pour moi, pas le fait que tu voies la modifs avec du retard. Ca, ça découle juste d'un autre problème à mon avis.