Discussion:
uur verschil in FAT timestamp
(te oud om op te antwoorden)
Martin Meijerink
2010-04-07 19:59:28 UTC
Permalink
Op 13 maart jl. om 10:30 maakte ik een foto.
Nu gebeurt dat natuurlijk wel vaker, maar dit even als voorbeeld.
Die foto heb ik destijds op mijn harddisk gezet (ext3), en het
originele kaartje (fat) heb ik nog, maar als ik beiden bekijk zie ik
toch een uur verschil:

***@tullamore:~# ls -l /ext/dcim/103msdcf/dsc37114.jpg
-rwxr-xr-x 1 root root 945299 2010-03-13 09:30 /ext/dcim/103msdcf/dsc37114.jpg
***@tullamore:~# ls -l /data/photos/incoming/dsc37114.jpg
-rwxr-xr-x 1 sepp users 945299 2010-03-13 10:30 /data/photos/incoming/dsc37114.jpg

(/ext/ is hierbij dus het geheugenkaartje en /data/ is mijn harde schijf)

Waarom geeft mijn pc nu aan dat op het originele kaartje de tijd ineens 09:30 is, terwijl dat in de wintertijd
nog 10:30 was? De bestanden op het kaartje zijn niet veranderd!
13 maart 10:30 moet 13 maart 10:30 blijven vind ik, ook als je in de zomer dit bestand bekijkt...
In de exifdata staat ook gewoon 10:30:

***@tullamore:~# jhead /ext/dcim/103msdcf/dsc37114.jpg|grep Date/Time
Date/Time : 2010:03:13 10:30:09

Wat is hier aan te doen, en hoe krijg ik mijn pc zo ver dat hij de juiste tijd van het bestand weergeeft?

mvg
Martin Meijerink
--
... Niets is zo irritant, als een spreuk aan de wand
--- Sylpheed 2.4.5 (GTK+ 2.12.0; i486-pc-linux-gnu)
* Origin: zutphen.nu (sepp.xs4all.nl [80.101.64.22])
Philip Paeps
2010-04-07 20:13:52 UTC
Permalink
Post by Martin Meijerink
Waarom geeft mijn pc nu aan dat op het originele kaartje de tijd ineens
09:30 is, terwijl dat in de wintertijd nog 10:30 was? De bestanden op het
kaartje zijn niet veranderd! 13 maart 10:30 moet 13 maart 10:30 blijven
vind ik, ook als je in de zomer dit bestand bekijkt...
Hoe moet dat bestand nu weten waar het gemaakt is? Stel dat je die foto in
Japan gemaakt had?
Post by Martin Meijerink
Wat is hier aan te doen, en hoe krijg ik mijn pc zo ver dat hij de juiste
tijd van het bestand weergeeft?
Helemaal niets. Het is geen probleem. De timestamp wordt in UTC bijgehouden
en ls toont je gewoon "local time" (op basis van /etc/localtime en/of $TZ).
Louter een kwestie van presentatie.

- Philip
--
Philip Paeps Please don't email any replies
***@paeps.cx I follow the newsgroup.

It does not matter if you fall down as long as you pick
up something from the floor while you get up.
Martin Meijerink
2010-04-08 06:05:52 UTC
Permalink
PP> Hoe moet dat bestand nu weten waar het gemaakt is? Stel dat je die
PP> foto in Japan gemaakt had?
Maakt me niet uit waar die gemaakt is, in de FAT entry staat het
volgende:

0000 44 53 43 33 37 31 31 34 4a 50 47 20 00 64 65 b9 DSC37114JPG .de.
0010 6e 3c 88 3c 00 00 c4 53 6d 3c 00 04 93 6c 0e 00 n<.<...Sm<...l..

Op offset 16 staat c4 53, oftewel 0x53c4
UUUUUMMMMMMSSSSS
In binair is dit 0101001111000100
Dus 01010 uur, 011110 minuten en 00100*2 seconden,
oftewel 10 uur, 30 minuten en 8 seconden (resolutie bij fat is nl. 2 sec)

Er staat gewoon maar 1 tijd, en dat is 10:30:08
En DIE tijd wil ik zien, of het nou zomer of winter is, of mijn klok
nou op UTC gebaseerd is of niet, als er 0x53c4 staat, staat er dus 10:30:08,
en wil ik dus dat deze tijd gewoon meegekopieerd.

PP> > Wat is hier aan te doen, en hoe krijg ik mijn pc zo ver dat hij
PP> > de juiste tijd van het bestand weergeeft?
PP>
PP> Helemaal niets. Het is geen probleem. De timestamp wordt in UTC
PP> bijgehouden en ls toont je gewoon "local time" (op basis
PP> van /etc/localtime en/of $TZ). Louter een kwestie van presentatie.

Maar waarom wordt er niet gewoon gepresenteerd wat er staat?
Er staat 10:30:08, ik zou zeggen: presenteer dat dan ook...
Of dat nou Japanse tijd is, dat is aan mij, ik kan aan de datum en de foto zelf
dan wel zien dat ik toen toevallig in Japan was... :)
--
... An unbreakable toy is useful to break other toys
--- Sylpheed 2.4.5 (GTK+ 2.12.0; i486-pc-linux-gnu)
* Origin: zutphen.nu (sepp.xs4all.nl [80.101.64.22])
jjg
2010-04-08 07:19:00 UTC
Permalink
Martin Meijerink wrote:
[...]
Post by Martin Meijerink
Maar waarom wordt er niet gewoon gepresenteerd wat er staat?
Er staat 10:30:08, ik zou zeggen: presenteer dat dan ook...
Of dat nou Japanse tijd is, dat is aan mij, ik kan aan de datum en de foto
zelf dan wel zien dat ik toen toevallig in Japan was... :)
Niets staat je in de weg, je eigen versie van ls te compileren. Je sloopt
gewoon de TZ correctie eruit, en je bent er :-)

Je kunt natuurlijk ook eens spelen met tzselect...
Rob
2010-04-08 08:00:20 UTC
Permalink
Post by jjg
[...]
Post by Martin Meijerink
Maar waarom wordt er niet gewoon gepresenteerd wat er staat?
Er staat 10:30:08, ik zou zeggen: presenteer dat dan ook...
Of dat nou Japanse tijd is, dat is aan mij, ik kan aan de datum en de foto
zelf dan wel zien dat ik toen toevallig in Japan was... :)
Niets staat je in de weg, je eigen versie van ls te compileren. Je sloopt
gewoon de TZ correctie eruit, en je bent er :-)
Dit "probleem" bevindt zich niet in "ls".

Je moet hier voor zoeken in de kernel, in het FAT filesystem.

Wat er gebeurt is dat de tijd die op de disk staat wordt terug gerekend
naar een UTC tijd, vervolgens wordt deze doorgegeven via de stat() system
call naar ls, en die rekent het dan weer om naar locale tijd.
Dit gebeurt zo omdat stat() nou eenmaal gedefinieerd is dat ie UTC terug
geeft.

Alleen gebeurt het omrekenen van locaal naar UTC in de kernel op een
andere manier dan van UTC naar locaal in "ls". Dus ontstaat er dan een
verschil.

Maar zoals gezegd, in Windows gebeurt het precies zo.
Er zal dus wel een goede reden zijn om deze truuk uit te halen, wellicht
dat het in bepaalde omstandigheden beter uit komt.
Rob
2010-04-08 08:05:46 UTC
Permalink
Post by Rob
Wat er gebeurt is dat de tijd die op de disk staat wordt terug gerekend
naar een UTC tijd, vervolgens wordt deze doorgegeven via de stat() system
call naar ls, en die rekent het dan weer om naar locale tijd.
Dit gebeurt zo omdat stat() nou eenmaal gedefinieerd is dat ie UTC terug
geeft.
Er bestaat overigens een mount optie om deze conversie te onderdrukken.

als je met de mount mee geeft: -o tz=UTC
dan zou de conversie niet meer gedaan worden.

Je krijgt dan de tijd op de disk terug als UTC tijd en deze wordt vervolgens
in Linux weer naar locale tijd omgerekend.

Dit gaat goed werken als je je camera op UTC tijd instelt.
Martin Meijerink
2010-04-09 19:57:48 UTC
Permalink
R> Rob <***@example.com> wrote:
R> > Wat er gebeurt is dat de tijd die op de disk staat wordt terug
R> > gerekend naar een UTC tijd, vervolgens wordt deze doorgegeven via
R> > de stat() system call naar ls, en die rekent het dan weer om naar
R> > locale tijd. Dit gebeurt zo omdat stat() nou eenmaal gedefinieerd
R> > is dat ie UTC terug geeft.
R>
R> Er bestaat overigens een mount optie om deze conversie te
R> onderdrukken.
R>
R> als je met de mount mee geeft: -o tz=UTC
R> dan zou de conversie niet meer gedaan worden.

Deze had ik in de manpages niet gevonden, maar dat komt dus omdat ik
nog met Ubuntu 7.10 werk, beetje oud inmiddels...
Op mijn laptop heb ik 9.10 staan, en daar ging het wel.
Ook daar heb ik even wat testjes gedaan:
Camera op 1 januari 12:00 PM gezet, foto dsc07477.jpg gemaakt,
Camera op 1 juli 12:00 PM gezet, foto dsc07478.jpg gemaakt,
hier de testresultaten:

Systeemdatum op februari (wintertijd) ingesteld:

***@waterford:~# mount /dev/sdb1 /ext/
***@waterford:~# ls -l /ext/dcim/101msdcf/dsc0747[78]* --full-time
-rwxr-xr-x 1 root root 103191 2009-01-01 12:00:08.000000000 +0100 /ext/dcim/101msdcf/dsc07477.jpg* (is goed!)
-rwxr-xr-x 1 root root 101775 2009-07-01 13:00:08.000000000 +0200 /ext/dcim/101msdcf/dsc07478.jpg* (is fout!)
***@waterford:~# umount /ext/

Systeemdatum op april (zomertijd) ingesteld:

***@waterford:~# mount /dev/sdb1 /ext/
***@waterford:~# ls -l /ext/dcim/101msdcf/dsc0747[78]* --full-time
-rwxr-xr-x 1 root root 103191 2009-01-01 11:00:08.000000000 +0100 /ext/dcim/101msdcf/dsc07477.jpg* (is fout!)
-rwxr-xr-x 1 root root 101775 2009-07-01 12:00:08.000000000 +0200 /ext/dcim/101msdcf/dsc07478.jpg* (is goed!)
***@waterford:~# umount /ext/

Oftewel, als ik foto's die ik gemaakt heb in de wintertijd, ook in de wintertijd naar mijn harddisk kopieer, dan wordt
de juiste tijd meegekopieerd.
En als ik foto's die ik gemaakt het in de zomertijd, ook in de zomertijd naar mijn harddisk kopieer, dan wordt ook de juiste tijd meegekopieerd.
Dus eigenlijk klopt de timestap op de definitieve plek van de foto's (mijn harddisk) gewoon altijd als ik me aan deze regels hou...

Systeemdatum op februari (wintertijd) ingesteld:

***@waterford:~# mount -o tz=UTC /dev/sdb1 /ext/
***@waterford:~# ls -l /ext/dcim/101msdcf/dsc0747[78]* --full-time
-rwxr-xr-x 1 root root 103191 2009-01-01 13:00:08.000000000 +0100 /ext/dcim/101msdcf/dsc07477.jpg*
-rwxr-xr-x 1 root root 101775 2009-07-01 14:00:08.000000000 +0200 /ext/dcim/101msdcf/dsc07478.jpg*
***@waterford:~# umount /ext/

Systeemdatum op april (zomertijd) ingesteld:

***@waterford:~# mount -o tz=UTC /dev/sdb1 /ext/
***@waterford:~# ls -l /ext/dcim/101msdcf/dsc0747[78]* --full-time
-rwxr-xr-x 1 root root 103191 2009-01-01 13:00:08.000000000 +0100 /ext/dcim/101msdcf/dsc07477.jpg*
-rwxr-xr-x 1 root root 101775 2009-07-01 14:00:08.000000000 +0200 /ext/dcim/101msdcf/dsc07478.jpg*
***@waterford:~# umount /ext/

Dit is dus inderdaad helemaal de goede oplossing, alleen niet voor mijn desktop... :(
En gewoon /bin/mount van mijn laptop kopieren naar mijn desktop is iets te simpel gedacht:

***@tullamore:~> ./mount
./mount: /lib/libblkid.so.1: no version information available (required by ./mount)
./mount: /lib/libblkid.so.1: no version information available (required by ./mount)
./mount: /lib/tls/i686/cmov/libc.so.6: version `GLIBC_2.7' not found (required by ./mount)

Maar aangezien ik de foto's altijd middels een scriptje naar mijn harddisk kopieer, valt hierin ook wel
een aanpassing in te scripten...

R> Je krijgt dan de tijd op de disk terug als UTC tijd en deze wordt
R> vervolgens in Linux weer naar locale tijd omgerekend.
R>
R> Dit gaat goed werken als je je camera op UTC tijd instelt.

In ieder geval allemaal bedankt voor het meedenken :)
--
... Ik ontken helemaal niets!
--- Sylpheed 2.4.5 (GTK+ 2.12.0; i486-pc-linux-gnu)
* Origin: zutphen.nu (sepp.xs4all.nl [80.101.64.22])
Dick Streefland
2010-04-13 14:27:40 UTC
Permalink
Martin Meijerink <***@zutphen.nu> wrote:
| Maar aangezien ik de foto's altijd middels een scriptje naar mijn harddisk kopieer, valt hierin ook wel
| een aanpassing in te scripten...

Met "jhead -ft" kun je de timestamp van de file zetten op de tijd uit
de EXIF header van de foto.
--
Dick
Martin Meijerink
2010-04-13 17:23:11 UTC
Permalink
DS> Martin Meijerink <***@zutphen.nu> wrote:
DS> | Maar aangezien ik de foto's altijd middels een scriptje naar mijn
DS> | harddisk kopieer, valt hierin ook wel een aanpassing in te
DS> | scripten...
DS>
DS> Met "jhead -ft" kun je de timestamp van de file zetten op de tijd
DS> uit de EXIF header van de foto.

idd, maar bij sommige sessies staan er alleen maar filmpjes op...

Maar het is al niet meer van toepassing (storm in een glas water
ofzoiets) De camera staat gewoon op lokale tijd, in oktober zet ik de
camera ook netjes een uur vooruit, en in maart zet ik hem een uur
achteruit.
Er is maar 1 ding waar ik aan moet denken, en dat is dat ik de foto's
(en filmpjes) kopieer in de periode wanneer ik ze ook gemaakt heb.
Dus de foto's die ik in de zomertijd maak, moet ik ook in de zomertijd
naar mijn harddisk kopieren, en de foto's die ik in de wintertijd maak,
moet ik ook in de wintertijd op mijn harddisk zetten.
En dat gaat in de praktijk dus bijna altijd vanzelf goed...
--
... Ik ontken helemaal niets!
--- Sylpheed 2.4.5 (GTK+ 2.12.0; i486-pc-linux-gnu)
* Origin: zutphen.nu (sepp.xs4all.nl [80.101.64.22])
John Bokma
2010-04-14 00:52:45 UTC
Permalink
Post by Martin Meijerink
DS> | Maar aangezien ik de foto's altijd middels een scriptje naar mijn
DS> | harddisk kopieer, valt hierin ook wel een aanpassing in te
DS> | scripten...
DS>
DS> Met "jhead -ft" kun je de timestamp van de file zetten op de tijd
DS> uit de EXIF header van de foto.
idd, maar bij sommige sessies staan er alleen maar filmpjes op...
Hebben de thumbs niet toevallig ook een time stamp in het thumb
bestandje zelf?
--
John Bokma j3b

Hacking & Hiking in Mexico - http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development
Martin Meijerink
2010-04-14 05:16:31 UTC
Permalink
JB> > DS> | Maar aangezien ik de foto's altijd middels een scriptje
JB> > DS> | naar mijn harddisk kopieer, valt hierin ook wel een
JB> > DS> | aanpassing in te scripten...
JB> > DS>
JB> > DS> Met "jhead -ft" kun je de timestamp van de file zetten op de
JB> > DS> tijd uit de EXIF header van de foto.
JB> >
JB> > idd, maar bij sommige sessies staan er alleen maar filmpjes op...
JB>
JB> Hebben de thumbs niet toevallig ook een time stamp in het thumb
JB> bestandje zelf?

Toevallig wel! :)
Goeie opmerking, had ik niet aan gedacht (ik negeerde die bestandjes
eigenlijk altijd...)
--
... Ik ontken helemaal niets!
--- Sylpheed 2.4.5 (GTK+ 2.12.0; i486-pc-linux-gnu)
* Origin: zutphen.nu (sepp.xs4all.nl [80.101.64.22])
John Bokma
2010-04-14 17:36:26 UTC
Permalink
Post by Martin Meijerink
JB> > DS> | Maar aangezien ik de foto's altijd middels een scriptje
JB> > DS> | naar mijn harddisk kopieer, valt hierin ook wel een
JB> > DS> | aanpassing in te scripten...
JB> > DS>
JB> > DS> Met "jhead -ft" kun je de timestamp van de file zetten op de
JB> > DS> tijd uit de EXIF header van de foto.
JB> >
JB> > idd, maar bij sommige sessies staan er alleen maar filmpjes op...
JB>
JB> Hebben de thumbs niet toevallig ook een time stamp in het thumb
JB> bestandje zelf?
Toevallig wel! :)
Goeie opmerking, had ik niet aan gedacht (ik negeerde die bestandjes
eigenlijk altijd...)
Ja, ik herkende je probleem ;-)
--
John Bokma j3b

Hacking & Hiking in Mexico - http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development
Rob
2010-04-07 20:28:52 UTC
Permalink
Post by Martin Meijerink
Waarom geeft mijn pc nu aan dat op het originele kaartje de tijd ineens 09:30 is, terwijl dat in de wintertijd
nog 10:30 was? De bestanden op het kaartje zijn niet veranderd!
13 maart 10:30 moet 13 maart 10:30 blijven vind ik, ook als je in de zomer dit bestand bekijkt...
Date/Time : 2010:03:13 10:30:09
Wat is hier aan te doen, en hoe krijg ik mijn pc zo ver dat hij de juiste tijd van het bestand weergeeft?
in het FAT filesystem staat de filetijd als locale tijd. in ext3 staat
deze als UTC. de routines die UTC vertalen naar locale tijd die houden
wel goed rekening met de zomertijd en de datum waarop deze ingaat en
eindigt.
maar bij het presenteren van de tijd van een FAT filesystem gaat dit
"niet goed". Overigens doet Microsoft Windows het precies zo, dus het
is niet onmogelijk dat men dit gedrag heeft ingebouwd om het in ieder
geval gelijk te maken aan wat Windows doet.

Ik kan me wel herrinneren dat we vroeger met Windows op FAT filesystem
ook dit soort ellende hadden, er werden bijvoorbeeld files gecopieerd
van de server (NTFS) naar de locale schijf (FAT32) op basis van modificatie
tijdstip (alleen nieuwere files) en als dat de tijd wisselde dan werd
de hele zooi opnieuw gecopieerd terwijl er niks veranderd was. Bij studie
bleek dan ook dat files ineens een ander tijdstip kregen bij die
wisseling.
Loading...