[quote=“zerimbak”]15h30 ??
Je l’ai envoyé à 16h30, l’heure indiquée en témoigne. Est-ce une plaisanterie ?
Il est 21h40 à l’heure où j’écris ce message.[/quote]
t’est pas a l’heure avec ton pc, c’est très courant. regarde du coter de l’horloge UTC, décalage horraire,locale (ou local, j’ai un doute )
avec google, aux besoins sépare ton problème d’heure, avec celui de make et poste le dans le forum de programation en précisent ce que tu as fait / pas fait etc.
c’est encore plus courant si tu utilise un o.s proprio
Cela date de vieux, mais j’ai eu un problème similaire à cause d’un
client/serveur ntp mal configuré.
En effet, j’ai des stations utilisateurs dont les disques ne
supportent que notre système d’exploitation préféré, les données se
trouvant sur une station centrale équipée d’un serveur nfs.
Mais, avec cette architecture, il est primordial de synchroniser
parfaitement toutes les stations.
Si tu es dans le même cas de figure, je te conseille donc de faire un
ntpq -p sur les stations incriminées.
J’ai enfin compris le problème mais je ne trouve pas la solution
voici ce que j’obtiens avec les commandes suivantes :
hwclock -r; date; date -u
sam. 28 avril 2012 21:58:40 CEST -0.414779 seconds
samedi 28 avril 2012, 21:58:40 (UTC+0200)
samedi 28 avril 2012, 19:58:40 (UTC+0000)
Attention, les bases de temps matériel (BIOS/RTC) et OS (linux par
ex), sont complètement déconnectées, sauf au démarrage s’il n’y a pas
de client ntp valide.
Si celui-ci peut se connecter à un serveur, l’horodatage s’effectue
par l’OS. Et s’il ne peut pas, c’est toujours l’OS qui opère, mais
évidemment avec comme base de départ l’horloge machine (RTC).
Par exemple sur ma machine, j’ai :
$ sudo hwclock -r; date; date -u
sam. 28 avril 2012 22:14:52 CEST -0.810958 seconds
samedi 28 avril 2012, 22:14:52 (UTC+0200)
samedi 28 avril 2012, 20:14:52 (UTC+0000) $
J’ai également un petit décalage, mais je n’ai pas tes problèmes.