est ce que quelqu'un peut m'expliquer le role de le 3 eme et de la 4 eme ligne du code dans laCode:time_t timestamp; struct tm *t; timestamp = time (NULL); t = localtime(×tamp);
Vous pouvez trouver la fonction complète sur ce lien:
http://membres.lycos.fr/dancel/c/c110_110.htm
Merci
Ben il me semble qu'il y a a peut prêt tout ce que tu veux dans le lien que tu donnes.
Sans doute y a t il des choses que tu ne comprends pas dedans...
Tu sais ce qu'est une structure ?
Je te donne une idée, tu me donnes une idée, nous avons chacun deux idées.
Pour une fois que tu as fais l'effort de la balise CODE, je me ferais un plaisir de t'aider, même si comme le dit zoup1 tout est compris dans le lien que tu fournis.Envoyé par lui
On commence par time_t qui est le type du temps (le deuxième t de time_t sous-entend type). C'est un entier en fait.
La fonction time te permet de récupérer le temps sous la forme d'un entier. Donc timestamp contient l'heure mais sous la forme d'un entier indiquant le nombre de secondes écoulées depuis le 1er janvier 1970 à 0 heure GMT. Juste après la ligne 3, affiche le contenu de timestamp et tu verras que ce n'est pas très agréable à lire. De plus, ça veut dire que tu dois t'amuser à le convertir en hh:mm:ss à chaque fois que tu compte l'utiliser... pas pratique. C'est là qu'intervient localtime et ctime.
Ne nous intéressons pas à ctime puisque ce n'est pas là l'objet de ta question.
La fonction localtime permet de convertir l'entier sous la forme d'un enregistrement (ce qu'on appelle souvent structure). Cet enregistrement contient un champ pour les minutes, les secondes, les jours etc. Voici la déclaration du type tm (c'est-à-dire de l'enregistrement du temps).
Donc dans ton exemple t.tm_yday te permet d'accéder au jour de l'année correspondant au temps que tu as récupéré à l'aide de time et qui autrement sera codé et illisible a priori.Code:struct tm { int tm_sec; /* Secondes */ int tm_min; /* Minutes */ int tm_hour; /* Heures (0 - 23) */ int tm_mday; /* Quantième du mois (1 - 31) */ int tm_mon; /* Mois (0 - 11) */ int tm_year; /* An (année calendaire - 1900) */ int tm_wday; /* Jour de semaine (0 - 6 Dimanche = 0) */ int tm_yday; /* Jour dans l'année (0 - 365) */ int tm_isdst; /* 1 si "daylight saving time" */ };
Est-ce clair ?
Bonjour,
On peut aussi préciser que localtime() tient compte du fuseau horaire de la machine. Des fois ça peut créer des surprises...
-- françois
Si je savais pas qu'est ce qu'une structure, j'aurai pas la possibilité de réaliser un programme en C qui contient plus de 1000 lignes de code de qui fonctionnne bien(Réponse pour le message de zoup1).
Dans celui ci, j'ai fait appele à la fonction localtime dont j'ai pas bien compris le fonctionnement surtout la ligneDans le lien, on trouve juste une explication de role général la fonction localtime qui convertie le nombre de secondes ecoulés depuis 01/01/1970.Code:timestamp = time (NULL);
Ce qui me pose un problème c'est la ligne ci dessus.
Donc si tu peux m'apporter une explication elle sera la bienvenue.
Merci d'avance!
Hola, faut pas te sentir agressé, moi je dis cela pour t'aider...
Sache au moins que les structures ne sont absolument pas indispensable à la réalisation de programme de plusieurs milliers de lignes qui fonctionnent très bien.
En ce qui concerne ton problème, c'est visiblement la fonction time() qui te pose problème. Je te propose donc d'aller voir dans le même document (http://membres.lycos.fr/dancel/c/c110_110.htm) je ne sais pas bien ce qu'on pourrais en dire de plus.Dans celui ci, j'ai fait appele à la fonction localtime dont j'ai pas bien compris le fonctionnement surtout la ligneDans le lien, on trouve juste une explication de role général la fonction localtime qui convertie le nombre de secondes ecoulés depuis 01/01/1970.Code:timestamp = time (NULL);
Ce qui me pose un problème c'est la ligne ci dessus.
Donc si tu peux m'apporter une explication elle sera la bienvenue.
Merci d'avance!
Je te donne une idée, tu me donnes une idée, nous avons chacun deux idées.
Je me sens pas agressé, juste pour et repondre à ta question.
MAintenant j'ai bien compris, en fait mon problème se situe au niveau de la fonction time() (j'ai pas vu sa définition au debut de lien).
Parcontre j'aurai une question sur un autre sujet:
Est ce que y a une moyen de faire un interface graphique pour un programme ecrit en C en gardant le meme programme.
Je te remercie beaucoup
Je vais me dispenser de répondre en détail à cette question car elle est trop générale..
La réponse est oui...
Après pour la pratique il faut choisir un environnement pour faire ton interface graphique. Ce choix dépend des contraintes que tu veux mettre sur ton interface. Par exemple si tu veux que ton programme fonctionne uniqument sous Windows ou uniquement sous MacOS ou uniquement sur Linux ou encore sur tout cela... cela conduit à des choix différents...
Pour ma part, j'ai abondonné l'utilisation d'interface graphique pour mes productions. J'utilise plutot des interfaces via le Web par exemple pour interagir avec mes oeuvres.
Je te donne une idée, tu me donnes une idée, nous avons chacun deux idées.
JE comprend pas qu'est ce que est l'interface via le web?
En fait comme je travaille sous Linux, je pense que celui ci fonctionnera seulement sous Linux
L'interface Web, ce sont des formulaire en html qui appelles des programmes...
Généralement ces programmes sont des script PHP, qui ont éventuellement la possiblité d'appeller des programme en C.
Si tu es sous Linux il y a des environnement de développement comme kde qui te proposes un environnement de travail qui te permet de créer "facilement" une interface graphique à travers l'environnement QT4 (je crois)
En fait il existe plein de façon différentes de faire... Une bonne pratique est de séparer complètement la partie calcul de la partie interface. Le mieux pour cela est de faire une interface graphique dans le système qui te plait... ce la peut-être du QT du Tk, du Java ou je ne sais quoi encore....
Je te donne une idée, tu me donnes une idée, nous avons chacun deux idées.
Bonjour,
Le post est assez ancien, mais je suis tombé dessus lors d'une recherche sur localtime, et j’avoue que vos explications mon bien aidé.
Je suis sur un petit serveur sous linux embarqué. J'ai réussi à implémenter le client NTP sur notre réseau local.
Dans mon ampli j'ai réussi, avec votre aide, à récupérer l'heure et la date grâce à localtime. Mais je ne suis pas localisé, car j'ai un décalage d'une heure.
Je n'est pas de fichier /etc/timezone. Il faut que j'en crée un mais je ne sais pas vraiment quoi lui mettre et éventuellement informer le système de l'utiliser, j’avoue que je ne suis pas vraiment à l'aise avec linux.
Je continu à chercher mais si une âme charitable peut me filer un coup de main.
A l'avenir ce paramètre doit pouvoir être paramétrable car nos systèmes s'exportent dans le monde entier.
Merci de votre aide
Plusieurs choses à clarifier:
Je ne comprends pas ce que tu veux dire par là, tu as configuré un serveur NTP sur votre réseau local est tu as réussi a installer un client NTP sur ton système embarqué qui utilise ton serveur local ? Ou bien tu as simplement installé un client NTP sur le système embarqué qui utilise un serveur NTP publique ?Je suis sur un petit serveur sous linux embarqué. J'ai réussi à implémenter le client NTP sur notre réseau local.
Je ne sais plus exactement comment ça marche et ça dépends de la distribution (il me semble que red-hat et debian ne font pas la même chose), attention également qu'en général LINUX attends une RTC en UTC, je pense que c'est au démarrage que la timezone est appliquée à l'heure UTC de la RTC (chercher "hwclock" dans les scripts d'initialisations, et son man).Dans mon ampli j'ai réussi, avec votre aide, à récupérer l'heure et la date grâce à localtime. Mais je ne suis pas localisé, car j'ai un décalage d'une heure.
ATTENTION, ce type de fonction (localtime, gettimeofday etc...) NE DOIVENT PAS ETRE UTILISEES POUR CALCULER UNE DUREE! Elle ne doivent être utilisées uniquement pour de la datation, en effet entre deux appels de "gettimeofday", ton horloge a pu ralentir (voir repartir en arrière) à cause de NTP, il faut donc utiliser une horloge monotonique.
Dernière remarque, si ton système doit être diffusé dans le monde entier, il faudrait que l'utilisateur puisse changer la "timezone" _ET_ le serveur NTP utilisé. Mais peut-être tu peux te simplifier la vie et n'utiliser que l'UTC.
Attention également, suivant comment tu utilises les dates, il y a beaucoup de chausse-trappes autour des "leap-seconds" et autres années bissextiles.
Bonjour, j'ai pas été très clair effectivement. J'ai un petit serveur DIGI 9210 dont l'OS est un linux embarqué que je créer a l'aide d’éclipse et une base fourni par DIGI.
On a un réseau local qui a son propre serveur NTP. Depuis le Serveur 9210 j'arrive a joindre le NTP et le serveur se met donc a jour mais avec une heure de décalage.Code:Réponse à la commande uname -a (Linux cme9210js 2.6.35.14 #1 Fri Jun 6 14:56:09 CEST 2014 armv5tejl GNU/Linux)
J'avoue que je suis un peu perdu. Le but final est d'avoir l'heure local du système bien sûr(afin que les données recueillies soit chronologiquement nommée), mais aussi de préparer le terrain pour mettre en place plus de sécurité sur nos serveurs, SSL etc... (Si besoin)
C'est clair qu'il faut que cela puisse être paramétrable, en ce qui concerne l'adresse du serveur NTP c'est fait mais pas pour la correction selon la zone géographique.
J'avais cru comprendre que la mécanique autour de localtime s'occupait des années bissextiles et heure d'été.
Comment utiliser uniquement l'UTC et est-ce que cela ne gène pas pour l'utilisation du SSL (Si cela est utile bien sûr)? Je suppose que c'est utile au vue des nombreux messages d'erreur obtenu lors d'une navigation sur le net avec un PC aillant l'horloge déréglé.
Merci
J'ai regardé rapidement, mais je continue, hwclock. cela existe bien dans mon serveur mais il m'indique-> Hwclock: can't open '/dev/misc/rtc'
Apparemment je risque d'être coincé pour un fonctionnement "automatique". Mes recherches mon amené a penser qu'il y a une base de données associer à tous cela. Base de donnée que ferait 3 ou 4 mega, information sur les villes etc... je n'est malheureusement pas cette place sur mon serveur. Actuellement je n'est plus que 500 K de dispo env., mais avec le SSL je ne passe deja pas. Nous envisageons de passer à un module (serveur DIGI) aillant le double de capacité, mais les dll SSL utilisera cette espace.
Il faut donc que je puisse trouvé un moyen de paramétrer mon système sans cette base de donnée.
Je pense donc que c'est bien un problème de "timezone" sur ton 9210, ils doivent être en UTC.On a un réseau local qui a son propre serveur NTP. Depuis le Serveur 9210 j'arrive a joindre le NTP et le serveur se met donc a jour mais avec une heure de décalage.
Pour ce type de problème, en général on reste en UTC de partout et on applique la correction "au plus proche" de l'interaction humaine. Je pense que pour la sécurité, les "timestamp" échangés sont en UTC puisqu'il faut une référence de temps commune et que les systèmes peuvent être sur des fuseaux horaires différent. Pour ce qui est de la datation des données, tu peux effectivement les dater selon le fuseau horaire où elles ont été acquises, mais il n'est pas forcément délirant de les dater en UTC (c'est même le plus simple si tu peux avoir deux systèmes sur des fuseaux horaires différents dont tu veux comparer les acquisitions). Tu peux imaginer apporter la correction du fuseau horaire uniquement à l'affichage de la datation par l'utilisateur par exemple.J'avoue que je suis un peu perdu. Le but final est d'avoir l'heure local du système bien sûr(afin que les données recueillies soit chronologiquement nommée), mais aussi de préparer le terrain pour mettre en place plus de sécurité sur nos serveurs, SSL etc... (Si besoin)
Je ne comprends pas ce que tu entends par automatique? Pour déterminer le fuseau horaire où tu es, il n'y a rien d'automatique, ta RTC est (à priori) en UTC, et tu configures manuellement ton fuseau horaire, comment veux-tu que le système connaisse sa position ? Il y a certainement une possibilité de l'automatiser si tu as un GPS, ou peut-être par ta "position réseau" (geoiplookup), mais ça n'aurait pas grand intérêt puisque la plupart des systèmes bougent peu. Et dans le cas d'un système itinérant, tous ceux que j'ai croisé (ou réalisé) sont en UTC.
Il faut donc que tu trouves sous quel fichier de périphérique la RTC est accessible. Mais ce n'était pas vraiment pour l'utiliser, mais plus pour lire sa page de manuel ou le retrouver dans les scripts d'initialisation (et éventuellement d'extinction).J'ai regardé rapidement, mais je continue, hwclock. cela existe bien dans mon serveur mais il m'indique-> Hwclock: can't open '/dev/misc/rtc'
Je prend note, et cela me parait logique. Un problème surement réglé pour le SSL.
Les utilisateurs, clients, ne sont pas à ma connaissance sur plusieurs méridien mais nous avons plusieurs clients (heureusement), mais je comprend l'idée, mais cela ne va pas leur plaire. Cela aurait été plus simple.
Le souci aussi c'est que mon petit serveur interroge une supervision (comme un automate mais de notre création), lui a sa propre base de temps. L'utilisateur final entre la date et heures local lors de la mise en service. On peut imaginer d’ailleurs que ce soit le serveur qui met à jour l'heure de la supervision, qui de plus ne gère pas du tout le passage à l'heure d'hiver/été.
Par contre l'idée est pas mauvaise, mais faudrait la faire accepter, car parfois on a des surprises lors de la création de courbes avec les données acquises si le client a modifié les heures des supervision pour le changement d'heure.
Quand je parle d'automatique c'est pas effectivement la position mais le calcul pour avoir l'heure local. L'utilisateur, ou du moins le technicien qui met en service, indique sa position ou en tout cas le méridien sur lequel il se trouve, afin d'avoir l'heure local. Les utilisateurs, souvent non technique, n’accepterait pas de voir l'heure UTC plutôt que l'heure local sur leur relevé, ou même sur la supervision deja qu'il la change lors d'un changement d'heure ce qui peut provoquer des erreurs sur les courbes comme j'ai deja dit plus haut.
.
Pour la création du linux, DIGI nous à donc donner un éclipse pré-paramétrée. Lors de la création on a une page de configuration afin de régler ce que l'on souhaite (si l'on veux un serveur http, smtp etc..) et notamment le RTC qui n'était pas activé. Pourtant l'heure tourne bien à chaque redémarrage en repartant de 1970 a chaque fois (si je ne démarre pas le deamon ntp), mais l'heure avance.
Je vous remercie énormément d'avoir pris le temps de m'expliquer pas mal de chose, mais je pense que cela serait mieux de créer un nouveau post, car la on va plus loin que le sujet de base.
Attention lorsqu'on parle de base de temps sur des systèmes distribués... la base (la référence, la date 0) doit être commune. On parle donc très souvent de date (ou temps) UNIX, i.e. le nb de secondes écoulées depuis le 1 janvier 1970 à 00h00 UTC. Donc les dates qui sont éventuellement échangée par NTP le serait en UTC, c'est au système qui se met à l'heure de corriger de son fuseau horaire, ne serait-ce que pour le cas ou le serveur NTM et le client ne sont pas sur le même fuseau horaire. Et corriger la datation peut se faire "à l'insu du client", i.e. ton programme "sait" le fuseau horaire, et c'est lui qui corrige la date UNX en date humaine (au lieu de s'appuyer sur la fonctionnalité du système). Attention, je ne dis pas que c'est une bonne solution, mais c'est une possibilité. De manière générale, il faut s'appuyer sur les fonctionnalités offertes par le système, je pense notamment à l'asservissement de l'heure que je te déconseille à faire toit même, c'est très casse-gueule surtout lorsqu'ils existent des solutions éprouvées comme NTP ou PTP.Le souci aussi c'est que mon petit serveur interroge une supervision (comme un automate mais de notre création), lui a sa propre base de temps. L'utilisateur final entre la date et heures local lors de la mise en service. On peut imaginer d’ailleurs que ce soit le serveur qui met à jour l'heure de la supervision, qui de plus ne gère pas du tout le passage à l'heure d'hiver/été.
Par contre l'idée est pas mauvaise, mais faudrait la faire accepter, car parfois on a des surprises lors de la création de courbes avec les données acquises si le client a modifié les heures des supervision pour le changement d'heure.
Nous sommes donc bien d'accord, l'utilisateur doit pouvoir renseigner sa position, ce qu'un outils système va "transformer" en "timezone" (décalage par rapport à greenwich, heure été / heure hiver et peut-être prochaine seconde intercalaire de prévue). Je pense que c'est facile de faire un petit script qui se lance si la timezone n'est pas configurée, le problème peut-être pour rendre permanente la config si ton système utilise un système de fichier en lecture seul.Quand je parle d'automatique c'est pas effectivement la position mais le calcul pour avoir l'heure local. L'utilisateur, ou du moins le technicien qui met en service, indique sa position ou en tout cas le méridien sur lequel il se trouve, afin d'avoir l'heure local. Les utilisateurs, souvent non technique, n’accepterait pas de voir l'heure UTC plutôt que l'heure local sur leur relevé, ou même sur la supervision deja qu'il la change lors d'un changement d'heure ce qui peut provoquer des erreurs sur les courbes comme j'ai deja dit plus haut.
Normal, la RTC ne sert que lorsque le système est hors-tension (si elle a une pile ou une alimentation permanente, sinon elle ne sert à rien). C'est pour ça que je te disait de chercher "hwclock" dans les scripts d'init. Au démarrage du système, l'OS va aller chercher la date actuelle dans la RTC, puis la fait vivre de manière indépendante, ça devient un compteur en RAM qui est incrémenté à chaque interruption du "tick". Le battement du tick peut alors être asservi de manière logiciel (NTP ou PTP), ou matériel (PPS de GPS, PTP + carte réseau) à une base de temps à priori plus stable que l'horloge du PC. Du coup, ton horloge système se désynchronise de ta RTC, il n'est donc pas rare de régler l'horloge RTC avec la date de l'heure système à l'extinction du système, et même d'estimer la dérive du quartz de la RTC par rapport à ton heure système, pour l'enregistrer et la lire au prochian redémarrage et ainsi corriger l'heure lue depuis la RTC avant de l'utiliser comme heure système.et notamment le RTC qui n'était pas activé. Pourtant l'heure tourne bien à chaque redémarrage en repartant de 1970 a chaque fois (si je ne démarre pas le deamon ntp), mais l'heure avance.
Pour me remercier ce sera le tutoiement...Je vous remercie énormément d'avoir pris le temps de m'expliquer pas mal de chose, mais je pense que cela serait mieux de créer un nouveau post, car la on va plus loin que le sujet de base.
J'y ai pensé, mais effectivement gerer les changements d'heure commence a être la galère.
On est d'accords.
Je ne suis pas en lecture seul pour le moment, a voir lorsque l'on utilisera le SSL. Dans la mesure du possible, pour le moment, j'essaie de ne pas modifier linux. Le lancement du client NTP, par exemple, je le lance depuis mon logiciel. On peut charger notre logiciel à distance par ftp et telnet. Puis après un reset il récupère les nouvelles fonctionnalité ou amélioration. Le changement de linux impose un flash sur place en TFTP, c'est très compliqué et coûteux à mettre en place sur les sites deja en place.
Je suppose qu'il faut quand même une base de données pour qu'il puisse changer l'heures en fonction de la position?
Le script ne peut pas être fabriquer puis lancé par mon logiciel ? De toute manière il faut qu'il soit modifiable afin de l'adapter en fonction du site.
Il donc que je trouve comment faire ce scrypt (pour avoir la base et essayer de le faire fonctionner) et ensuite voir comment on va gérer cela depuis la configuration du logiciel.
-----
J'ai un fichier de configuration qui permet au client de régler ces paramètres IP, fonctionnalité active ou pas (http, telnet transparent (convertisseur Ethernet/RS232), modbus IP, snmp et snmp trap, email etc..).
Soit c'est la supervision qui est prévu pour envoyé la configuration et le serveur met à jour son fichier.
Soit, sur les systèmes plus ancien, on a un petit logiciel PC qui va modifier les paramètres en telnet.
ok j'ai deja utiliser les DS1307 et c'est aussi ce que l'on utilise dans nos supervisions, je vois donc pas bien l’intérêt de cette fonction qui est disponible dans les choix de configuration DIGI puisque l'on a pas de pile dans le module DIGI, à moins que l'on puisse en brancher une en externe mais je n'est pas vu sa dans la doc.
Et bien je te remercie énormément.
Bonjour,
A l'aide d'un collègue on a réussi. Le système se met à l'heure en prenant les paramètre local.
Pour lancer le deamon ntp je lance la commande depuis mon logiciel par la commande:
Pour mettre l'heure à l'heure local je lance la commande:Code:system ("ntpd -d -p Nom_du_serveur");
Explication:Code:system("export TZ=WET-1WEST,M3.5.0/2,M10.5.0/2");
Reste maintenant à ce que ce soit mon logiciel PC, pour paramétrer le fichier de configuration de mon petit serveur DIGI, qui fabrique la ligne de commande, par forcement buvable pour monsieur tout le monde.WET = West Europe Time à -1 heure vers l'ouest par rapport au temps universel
WEST = West Europe Summer Time défini comme :
dernier (5) dimanche (0) de mars (3) à 2 h pour début
dernier (5) dimanche (0) d'octobre (10) à 2 h pour fin
Apparemment il y a une base de données accessible sur internet, à voir.
Il me reste aussi à voir:
Si je peux ajouter plusieurs serveur à ma ligne de commande ntpd.
c'est "TZ database", à une époque sous linux tu avais une image locale ce cette base de donné (/etc/tzdata ?), néanmoins, il faudra quand même changer le choix utilisateur en une entrée dans cette bdd.Apparemment il y a une base de données accessible sur internet, à voir.
Tu peux mettre des serveurs NTP dans le fichier de configuration (/etc.ntp.conf ?)Si je peux ajouter plusieurs serveur à ma ligne de commande ntpd.
Tu as également les "pool": des adresses qui pointent vers plusieurs serveurs NTP, avec l'avantage que ces "pool" sont (en général) mis à jour en fonction des dispo des serveurs NTP
Ce que je comptais plus faire c'est charger ou utiliser directement sur le net cette base de données dans mon logiciel PC et envoyer juste la ligne de commande dans le fichier de configuration de mon serveur. Si je peut avoir cette base en local avec mon logiciel sur le PC ce serait plus pratique si le client n'a pas d'acces a internet. (J'ai pas du tout encore regardé les possibilités).
Je n'est pas de fichier ntp.conf dans etc, par contre j'y suis arrivé, avec la même commande en ajoutant un autre -p nom_du_serveur2. J'ai vu que je pouvais installer dans la distri linux openNTP et la il parle de ce fichier ntp.conf. Je suis pas sur que mon deamon ntpd puisse l'utiliser, mais j 'ai pas essayé, et ne souhaitant pas modifier linux si j'ai pas besoin d'utilise openntp c'est parfait.
Je suis obligé de mettre à chaque fois -p, cela me surprend mais cela fonctionne. J'ai testé en mettant à la place des adresses existante mais pas pour le NTP genre www.google.fr www.google.com plus une adresse valide. En inter-changeant cette adresse valide de place. Cela fonctionne à chaque fois, c'est juste plus ou moins long suivant la place ou se trouve l'adresse valide.ntpd -d -p serveur1 -p server2 -p server3
J'ai réussi à activer les DNS sur mon serveur bien-sur.
Pratique les "pool", je connaissais pas.
Donc il me reste a mettre tout sa en place dans mon logiciel embarqué (pour le moment j'ai lancé les commandes par telnet), et a modifier mon logiciel PC de configuration avec cette base de données TZ.
Merci encore
Je viens de penser à un truc tout bête, mais mon logiciel PC de configuration peut surement utiliser la base de donné du PC. Ce dernier même non connecté à internet a bien sa base.
