05-11-18, 05:58
(Modification du message : 06-11-18, 15:03 par jean-thevenet.)
il ya un bug de concept pour l'heure locale et l'heure GMT dans les appareils photos, car le décalage se rattrape dans les métadonnées mais pas pour l'heure d'enregistrement des fichiers (impossible de concilier les deux tout en ayant un appareil photo qui affiche l'heure locale (et aussi pour la caméscope sauf en réglant l'heure locale sur "santiago du chili" (GMT-4).. pour l'île de la Réunion GMT+4)).
c'est pourtant très simple d'usage: si on règle l'appareil photo à l'heure GMT, on choisi le fuseau horaire du pays visité et les métadonnés sont bien à l'heure du pays, mais pas les fichiers sur la carte mémoire auquel le système ajoute le décalage horaire du pays à l'importation (ce qui donne GMT +8 au lieu de GMT+4). Pour les fichiers, ça ne marche que si on régle tout à l'heure GMT (l'horloge indique l'heure de londre ET SANS RÉGLER LE FUSEAU HORAIRE) c'est OK pour les fichiers, mais là ça ne marche plus avec Darktable dans la zone du pays et on a des appareils photo qui affichent l'heure de Londre.
L'interface linux se considère à l'heure locale et traduit en heure locale l'heure des fichiers informatique provenant de l'extérieur, censés être en heure GMT.
Les concepteurs ont voulu résoudre le problème de celui qui veut que ça affiche toujours l'heure de la montre et ont décidé de régler automatiquement l'heure affichée à celle de la montre du pays visité quand on choisi le fuseau horaire, mais sans revoir semble-il fort pour l'enregistrement des fichiers informatiques que on a voulu rattraper l'heure du fuseau-horaire déjà une fois pour les fichiers. Ça ne fonctionne donc pas avec un appareil photo réglé à l'heure GMT puis ajusté sur le fuseau horaire du pays, par ce que l'appareil photo enregistre l'heure locale en date d'enregistrement du fichier en tenant compte du fuseau choisi et non l'heure GMT et que le système refait cette opération de traduction, c'est une fois de trop!
D'où à la Réunion +4h + le fuseau horaire ajouté par le système d'exploitation qui considère que le fichier est inscrit en heure GMT et ajoute donc +4h de plus => GMT+8
sékon
et en plus, en France, quand le soleil tape sur le système... on cherche midi à 14h, carrément.. car il ya l'heure d'été et d'hiver pour compliquer encore!
pourquoi faire simple quand on peut faire compliqué?! si on en est là, c'est peut être par ce que ne plus vivre à l'heure locale solaire a tellement coupé des perceptions de la géométrie des cycles horaires et des symétries midi minuit, après-midi et matin, qu'on se plante lamentablement en écrivant les logiciels!
c'est pourtant très simple d'usage: si on règle l'appareil photo à l'heure GMT, on choisi le fuseau horaire du pays visité et les métadonnés sont bien à l'heure du pays, mais pas les fichiers sur la carte mémoire auquel le système ajoute le décalage horaire du pays à l'importation (ce qui donne GMT +8 au lieu de GMT+4). Pour les fichiers, ça ne marche que si on régle tout à l'heure GMT (l'horloge indique l'heure de londre ET SANS RÉGLER LE FUSEAU HORAIRE) c'est OK pour les fichiers, mais là ça ne marche plus avec Darktable dans la zone du pays et on a des appareils photo qui affichent l'heure de Londre.
L'interface linux se considère à l'heure locale et traduit en heure locale l'heure des fichiers informatique provenant de l'extérieur, censés être en heure GMT.
Les concepteurs ont voulu résoudre le problème de celui qui veut que ça affiche toujours l'heure de la montre et ont décidé de régler automatiquement l'heure affichée à celle de la montre du pays visité quand on choisi le fuseau horaire, mais sans revoir semble-il fort pour l'enregistrement des fichiers informatiques que on a voulu rattraper l'heure du fuseau-horaire déjà une fois pour les fichiers. Ça ne fonctionne donc pas avec un appareil photo réglé à l'heure GMT puis ajusté sur le fuseau horaire du pays, par ce que l'appareil photo enregistre l'heure locale en date d'enregistrement du fichier en tenant compte du fuseau choisi et non l'heure GMT et que le système refait cette opération de traduction, c'est une fois de trop!
D'où à la Réunion +4h + le fuseau horaire ajouté par le système d'exploitation qui considère que le fichier est inscrit en heure GMT et ajoute donc +4h de plus => GMT+8
sékon
et en plus, en France, quand le soleil tape sur le système... on cherche midi à 14h, carrément.. car il ya l'heure d'été et d'hiver pour compliquer encore!
pourquoi faire simple quand on peut faire compliqué?! si on en est là, c'est peut être par ce que ne plus vivre à l'heure locale solaire a tellement coupé des perceptions de la géométrie des cycles horaires et des symétries midi minuit, après-midi et matin, qu'on se plante lamentablement en écrivant les logiciels!