[opensuse] vfat timestamp again
Hello: I took photos with a digital camera which saves the photos to a vfat formatted sdcard. The camera's clock is set correctly according to my local time. When I mount the vfat filesystem in openSUSE 13.2 using a card reader, the timestamps the photos are 2 hours ahead. (OpenSUSE 13.2 system time is set to UTC.) Eg. timestamp shows 18:20 instead of 16:20, the time when the photo was actually taken. I find this behavior - again - unacceptable, ridiculous, and annoying. Isn't there any option with which this stupid behavior could be changed so that the filesystem times would be interpreted as the user's local time? Is this so big expectation? I would like to archive the images, and therefore the timestamps applied at mounting will be preserved. I don't want to archive wrong timestamps, because it is important when the photos were taken. I know I can look at metainfo, but it is not real a solution. What I want is changing the timestamps applied when the filesystem is mounted. Thanks, Istvan -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/27/2015 02:57 PM, Istvan Gabor wrote:
What I want is changing the timestamps applied when the filesystem is mounted.
Back when FAT was created for DOS, the concept of time zones was unknown to computers. Therefore, there is no way to know what the time zone was. If you set your computer desktop to local time, instead of UTC, they'd have the correct time. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2015-05-27 21:09, James Knott wrote:
On 05/27/2015 02:57 PM, Istvan Gabor wrote:
What I want is changing the timestamps applied when the filesystem is mounted.
Back when FAT was created for DOS, the concept of time zones was unknown to computers. Therefore, there is no way to know what the time zone was. If you set your computer desktop to local time, instead of UTC, they'd have the correct time.
That is so. And anyway, the photos have the correct timestamp inside, in the exif metadata. The file time should be ignored. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/27/2015 12:21 PM, Carlos E. R. wrote:
On 2015-05-27 21:09, James Knott wrote:
On 05/27/2015 02:57 PM, Istvan Gabor wrote:
What I want is changing the timestamps applied when the filesystem is mounted.
Back when FAT was created for DOS, the concept of time zones was unknown to computers. Therefore, there is no way to know what the time zone was. If you set your computer desktop to local time, instead of UTC, they'd have the correct time.
That is so.
I doubt there was ever a time when time zone was unknown by computers.
And anyway, the photos have the correct timestamp inside, in the exif metadata. The file time should be ignored.
If the camera's clock is wrong, the EXIF will be wrong. If the camera's clock is UTC, why would the FAT use anything other? - -- After all is said and done, more is said than done. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlVmKIkACgkQv7M3G5+2DLIZZQCgpo695w6JhSn9pOKiMDT3SXZO 3qQAoIXOYcfEsfLo5izL74chig4t4lB8 =fybE -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/27/2015 04:26 PM, John Andersen wrote:
I doubt there was ever a time when time zone was unknown by computers.
The first "DOS" computers didn't even come with a real time clock and even minicomputers used a software clock. There was no allowance for UTC etc., as computers didn't have any need to deal with it. However, that changed with networks and particularly the Internet. Back in the late 90s, I worked at IBM Canada and often had to logon to servers across the country. Every time I connected to a server in a different time zone, my computer clock time would change. This is because the OS/2, like Windows, servers didn't support time zones. This compares with Linux & Unix, where the computer clock is often set to UTC and then offset for the displayed time. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2015-05-27 22:26, John Andersen wrote:
On 05/27/2015 12:21 PM, Carlos E. R. wrote:
I doubt there was ever a time when time zone was unknown by computers.
MsDOS had no idea at all of time zone. The time was always "local". You look at the timestamp of a file in France, say 03:00 AM. You take the 5¼ floppy to another MsDOS computer in Australia, look at the timestamp, and it is still the same, 03:00 AM. Nowhere is stored the information as to _where_ that 03:00 AM was. There was no Internet. The IBM PC didn't even have a clock: you had to type the time and date every time you booted it. Many people simply hit enter, so that many files were dated 1970 00:02 AM or something similar, I forget the exact figure.
And anyway, the photos have the correct timestamp inside, in the exif metadata. The file time should be ignored.
If the camera's clock is wrong, the EXIF will be wrong.
Who says the camera clock is wrong? Look at the original post, the time is correct.
If the camera's clock is UTC, why would the FAT use anything other?
The camera clock is not UTC, and FAT uses nothing. FAT can not store timezone information, as simple as that. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Wed, May 27, 2015 at 4:42 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
And anyway, the photos have the correct timestamp inside, in the exif metadata. The file time should be ignored.
If the camera's clock is wrong, the EXIF will be wrong.
Who says the camera clock is wrong? Look at the original post, the time is correct.
If the camera's clock is UTC, why would the FAT use anything other?
The camera clock is not UTC, and FAT uses nothing. FAT can not store timezone information, as simple as that.
--
Maybe this is a dumb question, but I routinely work with timestamps when coding in Perl. The libraries I use for this permits creating timestamps without a time zone, and then it is trivial to add a time zone to each (e.g. changing "2015-05-27 04:58:32" to "2015-05-27 04:58:32 EST"). Is it not possible to do something similar using a shell script when copying files from the sdcard (I do not do much shell scripting so I don't know)? Or do those timestamps get converted to UTC the moment it is plugged into the computer? Now, in my work, I never rely on timestamps used on the file system, but this issue piqued my curiousity, and the answer might help the OP. Cheers Ted -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2015-05-27 23:07, Ted Byers wrote:
On Wed, May 27, 2015 at 4:42 PM, Carlos E. R. <> wrote:
Maybe this is a dumb question, but I routinely work with timestamps when coding in Perl. The libraries I use for this permits creating timestamps without a time zone, and then it is trivial to add a time zone to each (e.g. changing "2015-05-27 04:58:32" to "2015-05-27 04:58:32 EST"). Is it not possible to do something similar using a shell script when copying files from the sdcard (I do not do much shell scripting so I don't know)? Or do those timestamps get converted to UTC the moment it is plugged into the computer? Now, in my work, I never rely on timestamps used on the file system, but this issue piqued my curiousity, and the answer might help the OP.
The problem is that FAT filesystem can in no way store the full time stamp. It is just a date/day longint (I don't remember, I could check), and the time zone or difference to UTC is simply not stored. It was assumed that it meant "local time", regardless of where the computer was. Open a file anywhere, and it just displays the same date/time string. Linux, on the other hand, on Linux filesystems, assumes UTC (not really, but never mind), and calculates the correct time for the timezone each of the multiple users request. Thus it is always displayed correctly. But Linux (or Windows) have no way to know what time zone the "local" time of an vfat file means. It assumes it is the same as the "local" time of the machine. I don't know whose local time, though: the user that does the mount, probably, but maybe the one that does the reading. Dunno. Yes, you could script something to correct the timestamps using "touch". Get timestamp using exif data, and touch the destination file to the correct time. Yes, doable. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Ted Byers írta:
On Wed, May 27, 2015 at 4:42 PM, Carlos E. R. wrote:
And anyway, the photos have the correct timestamp inside, in the exif metadata. The file time should be ignored.
If the camera's clock is wrong, the EXIF will be wrong.
Who says the camera clock is wrong? Look at the original post, the time is correct.
If the camera's clock is UTC, why would the FAT use anything other?
The camera clock is not UTC, and FAT uses nothing. FAT can not store timezone information, as simple as that.
--
Maybe this is a dumb question, but I routinely work with timestamps when coding in Perl. The libraries I use for this permits creating timestamps without a time zone, and then it is trivial to add a time zone to each (e.g. changing "2015-05-27 04:58:32" to "2015-05-27 04:58:32 EST"). Is it not possible to do something similar using a shell script when copying files from the sdcard (I do not do much shell scripting so I don't know)? Or do those timestamps get converted to UTC the moment it is plugged into the computer? Now, in my work, I never rely on timestamps used on the file system, but this issue piqued my curiousity, and the answer might help the OP.
I guess mount should have an option for specifying how to interpret timestamps exactly. For example the user could use: mount /dev/sdc1 /mnt1 -o TZ=UTC+2h or something similar. Thanks, Istvan -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Istvan Gabor wrote:
I guess mount should have an option for specifying how to interpret timestamps exactly. For example the user could use:
mount /dev/sdc1 /mnt1 -o TZ=UTC+2h
Locale-information is not a job for mount - sounds more like you should specify TZ when accessing the contents. -- Per Jessen, Zürich (15.5°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, May 28, 2015 at 12:56 PM, Per Jessen <per@computer.org> wrote:
Istvan Gabor wrote:
I guess mount should have an option for specifying how to interpret timestamps exactly. For example the user could use:
mount /dev/sdc1 /mnt1 -o TZ=UTC+2h
Locale-information is not a job for mount - sounds more like you should specify TZ when accessing the contents.
??? And how is it going to help? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrei Borzenkov wrote:
On Thu, May 28, 2015 at 12:56 PM, Per Jessen <per@computer.org> wrote:
Istvan Gabor wrote:
I guess mount should have an option for specifying how to interpret timestamps exactly. For example the user could use:
mount /dev/sdc1 /mnt1 -o TZ=UTC+2h Locale-information is not a job for mount - sounds more like you should specify TZ when accessing the contents.
??? And how is it going to help?
I was thinking out loud - wouldn't e.g. "ls" list timestamps according to TZ? TZ=UTC ls -l /Per -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2015-05-28 11:44, Istvan Gabor wrote:
I guess mount should have an option for specifying how to interpret timestamps exactly. For example the user could use:
mount /dev/sdc1 /mnt1 -o TZ=UTC+2h
It does: The man page documents "tz=UTC": tz=UTC This option disables the conversion of timestamps between local time (as used by Windows on FAT) and UTC (which Linux uses internally). This is particularly useful when mounting devices (like digital cameras) that are set to UTC in order to avoid the pitfalls of local time. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 05/28/2015 09:00 AM, Carlos E. R. wrote:
This is particularly useful when mounting devices (like digital cameras) that are set to UTC in order to avoid the pitfalls of local time.
Hmm. I know a couple of people who have their wrist-watches set to UTC. They perform the conversion to local time 'in their head'. What they have in common is that they are aviators. It works for them, so I don't see why it shouldn't work for other use-cases :-) Personally I'd prefer to have a app on my phone, which I use as a timepiece rather than something bolted to my body, that supports multiple time zones. But then again, I'm not travelling between time zones often. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2015-05-28 15:08, Anton Aylward wrote:
On 05/28/2015 09:00 AM, Carlos E. R. wrote:
This is particularly useful when mounting devices (like digital cameras) that are set to UTC in order to avoid the pitfalls of local time.
Hmm. I know a couple of people who have their wrist-watches set to UTC. They perform the conversion to local time 'in their head'.
What they have in common is that they are aviators.
:-) Or radio amateurs, those that try international communications. Astronomers, too.
It works for them, so I don't see why it shouldn't work for other use-cases :-)
Mmm.
Personally I'd prefer to have a app on my phone, which I use as a timepiece rather than something bolted to my body, that supports multiple time zones. But then again, I'm not travelling between time zones often.
It doesn't work always right. At least on Android 2 the time source of preference is supplied by the phone company, via a GSM protocol (I don't remember the exact name now). This depends on your phone company supporting it, and many don't do it completely. If I could remember the name I could post the link to an article, I think on the wikipedia, that lists support of the protocol by companies. Ah, NITZ. Network Identity and Time Zone http://en.wikipedia.org/wiki/NITZ I have traveled a bit, and on some countries the clock was correct, and not on others. On mine, Movistar doesn't feed time zone info. NITZ is not officially supported (http://comunidad.movistar.es/t5/Soporte-T%C3%A9cnico-Servicios/error-en-zona...). On Android phones, NTP or GPS could be used as time source. There are apps to do this, but the phone has to be rooted for this to work (automatically). https://code.google.com/p/android/issues/detail?id=4581 I use this one: https://play.google.com/store/apps/details?id=ru.org.amip.ClockSync I think other versions of Android handle time better. But not all: I have an install in vmware, and it doesn't. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 05/28/2015 09:43 AM, Carlos E. R. wrote:
What they have in common is that they are aviators. :-)
Or radio amateurs, those that try international communications. Astronomers, too.
In fact, many industries use UTC. I used to work for a telecom carrier, where UTC was used. In fact, UTC is useful for any business that works across time zones. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/28/2015 09:43 AM, Carlos E. R. wrote:
On Android phones, NTP or GPS could be used as time source. There are apps to do this, but the phone has to be rooted for this to work (automatically). https://code.google.com/p/android/issues/detail?id=4581
I use this one: https://play.google.com/store/apps/details?id=ru.org.amip.ClockSync
I also use ClockSync. My phone's time is always within a fraction of a second of ClockSync time. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/28/2015 09:00 AM, Carlos E. R. wrote:
This is particularly useful when mounting devices (like digital cameras) that are set to UTC in order to avoid the pitfalls of local time.
It occurs to me ... My camera is GPS enabled and it also records the GPS satellite time as well as the longitude at which the photograph was taken. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/28/2015 06:13 AM, Anton Aylward wrote:
It occurs to me ... My camera is GPS enabled and it also records the GPS satellite time as well as the longitude at which the photograph was taken.
Most of the time. I found this to fail (no gps coordinates/time) often, such as when you quickly power on the camera and start shooting before the GPS settles. I imagine that varies by brand. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/27/2015 12:21 PM, Carlos E. R. wrote:
And anyway, the photos have the correct timestamp inside, in the exif metadata. The file time should be ignored.
But he needs to quickly find files dated with a certain date..... Jhead can do this for him http://linux.die.net/man/1/jhead http://www.sentex.net/~mwandel/jhead/ - -- After all is said and done, more is said than done. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlVmKoAACgkQv7M3G5+2DLLUIQCgrdezy4CG6Pdbyp+cT1a7yesJ O1EAn3KR0wer0Y9eXqmjZCkFEP6Cv89m =A14Q -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2015-05-27 22:35, John Andersen wrote:
On 05/27/2015 12:21 PM, Carlos E. R. wrote:
And anyway, the photos have the correct timestamp inside, in the exif metadata. The file time should be ignored.
But he needs to quickly find files dated with a certain date.....
Which you do simply by using a good application to retrieve and organize photos from cameras. For instance, shotwell. It is automatic. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
* Carlos E. R. <robin.listas@telefonica.net> [05-27-15 16:50]:
On 2015-05-27 22:35, John Andersen wrote:
On 05/27/2015 12:21 PM, Carlos E. R. wrote:
And anyway, the photos have the correct timestamp inside, in the exif metadata. The file time should be ignored.
But he needs to quickly find files dated with a certain date.....
Which you do simply by using a good application to retrieve and organize photos from cameras. For instance, shotwell. It is automatic.
Or use a file-system understanding dates and a script to make the file dates the same as the exif date: exiv2 -T ./*.{nef,jpg} Same can be done with exiftool but much slower: exiftool -overwrite_original -DateTimeOriginal>FileModifyDate ./*.{nef,jpg} -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/27/2015 03:21 PM, Carlos E. R. wrote:
On 2015-05-27 21:09, James Knott wrote:
On 05/27/2015 02:57 PM, Istvan Gabor wrote:
What I want is changing the timestamps applied when the filesystem is mounted.
Back when FAT was created for DOS, the concept of time zones was unknown to computers. Therefore, there is no way to know what the time zone was. If you set your computer desktop to local time, instead of UTC, they'd have the correct time.
That is so.
And anyway, the photos have the correct timestamp inside, in the exif metadata. The file time should be ignored.
+1 -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward írta:
On 05/27/2015 03:21 PM, Carlos E. R. wrote:
On 2015-05-27 21:09, James Knott wrote:
On 05/27/2015 02:57 PM, Istvan Gabor wrote:
What I want is changing the timestamps applied when the filesystem is mounted.
Back when FAT was created for DOS, the concept of time zones was unknown to computers. Therefore, there is no way to know what the time zone was. If you set your computer desktop to local time, instead of UTC, they'd have the correct time.
That is so.
And anyway, the photos have the correct timestamp inside, in the exif metadata. The file time should be ignored.
+1
Anton and others, who suggest extracting time stamps from exif, probably haven't read the OP carefully. Though it is a workaround for the problem it is tedious and I don't find it a "solution". The jhead program John suggested seems simpler at first view than other similar methods. But files on vfat can be without exif information, eg sound files or text files, how can I extract the timestamp then? The right way would be to add an option to mount where the user can specify how to interpret the timestamps. Thanks for the suggestions, Istvan -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, May 28, 2015 at 12:15 PM, Istvan Gabor <suseuser04@freemail.hu> wrote:
But files on vfat can be without exif information, eg sound files or text files, how can I extract the timestamp then? The right way would be to add an option to mount where the user can specify how to interpret the timestamps.
This already exists: time_offset=<minutes>. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrei Borzenkov írta:
On Thu, May 28, 2015 at 12:15 PM, Istvan Gabor wrote:
But files on vfat can be without exif information, eg sound files or text files, how can I extract the timestamp then? The right way would be to add an option to mount where the user can specify how to interpret the timestamps.
This already exists: time_offset=<minutes>.
Thanks! This option works in oS 13.2 (doesn't work in oS 12.2). Where is it documented? The mount 2 man page doesn't mention it in oS 13.2. Istvan -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
В Thu, 28 May 2015 12:08:16 +0200 (CEST) Istvan Gabor <suseuser04@freemail.hu> пишет:
Andrei Borzenkov írta:
On Thu, May 28, 2015 at 12:15 PM, Istvan Gabor wrote:
But files on vfat can be without exif information, eg sound files or text files, how can I extract the timestamp then? The right way would be to add an option to mount where the user can specify how to interpret the timestamps.
This already exists: time_offset=<minutes>.
Thanks! This option works in oS 13.2 (doesn't work in oS 12.2).
Where is it documented? The mount 2 man page doesn't mention it in oS 13.2.
I know readme in kernel tree. And do not forget that it is best effort workaround at best. Even if all content of FAT was created in the same geographical region you still have daylight saving time difference. So some timestamps may be off by one hour. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2015-05-28 14:01, Andrei Borzenkov wrote:
В Thu, 28 May 2015 12:08:16 +0200 (CEST) Istvan Gabor <> пишет:
Where is it documented? The mount 2 man page doesn't mention it in oS 13.2.
I know readme in kernel tree.
It should be in the man page.
And do not forget that it is best effort workaround at best. Even if all content of FAT was created in the same geographical region you still have daylight saving time difference. So some timestamps may be off by one hour.
More interesting is option "tz=UTC" -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 05/28/2015 05:15 AM, Istvan Gabor wrote:
Anton and others, who suggest extracting time stamps from exif, probably haven't read the OP carefully.
Well, Gee, I don't know about "others" since I'm not a mind reader, but what I was agreeing with was that <quote> ... the photos have the correct timestamp inside, in the exif metadata. </quote> When I process my photos 'incoming' from my camera I run an exif command (as a script, Linux is good with scripts! that converts the camera's name for the file to a day-date string and sorts them into a year-month directory. It may happen that I don't use my camera often for a period of time so there could well be three or four months worth of files. Camera users know that a 16G card can hold many, many hundreds of photographs. I can't imagine why anyone serious about the craft would dream of processing input one by one by hand! "Automate!", that's the thing, eh Patrick? "Tedious"? Only if you choose to do things manually. I don't. Personally I'm disappointed in the world at large for settling for such a primitive file type. I'm even more disjointed that so many firms settled in to Microsoft bullying about licensing it, claiming a patent on a design that goes back though CP/M to RSTS and even the PDP-8.
But files on vfat can be without exif information, eg sound files or text files
Please don't blame vfat for that. It is not the responsibility of the file system to carry such information. Example: I create an image on a Linux machine and a ext4 file system. The image has internal metadata time stamp and the file i-node has information that includes three time fields Access: last time the contents of the file were examined. Modify: Last time the contents of the file were changed. Change: Last time the file's inode was changed. One might think that "Modify" is the same as the exif time stamp but that is not so. The example I gave above of a delayed upload illustrates that for Linux as well as for "DOS".
The right way would be to add an option to mount where the user can specify how to interpret the timestamps.
And how is that different from the (automated) way I process my incoming files as I described above. The file NAME is the real timestamp. That is regardless of the file system. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2015-05-28 14:26, Anton Aylward wrote:
"Tedious"? Only if you choose to do things manually. I don't.
Programs like shotwell organize photos in directories organized by dates correctly, it seems. I suppose digikam does similarly. Before those, I also created my own script to label the photos extracted from my old nokia phone, which did not mount at all. A special program had to be used.
Personally I'm disappointed in the world at large for settling for such a primitive file type.
Because it is a "good" filesystem :-p Really, it is. There are better, of course. For the media used in cameras and sticks, there is a new filesystem type optimized for such media. Not exfat. I can't remember the name. It is open. Samsung is one of the partners. Actually, the timestamp problem with FAT is not that it does not store timezone information, because (I have just realized) Linux filesystems don't, as well. The issue is that the convention is to assume "local" time instead of UTC. And according to this entry in the mount man page: tz=UTC This option disables the conversion of timestamps between local time (as used by Windows on FAT) and UTC (which Linux uses internally). This is particularly useful when mounting devices (like digital cameras) that are set to UTC in order to avoid the pitfalls of local time. Thus I understand that cameras, or some cameras, actually use UTC internally. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Thu, May 28, 2015 at 4:25 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
Actually, the timestamp problem with FAT is not that it does not store timezone information, because (I have just realized) Linux filesystems don't, as well.
They do. Timestamp is stored in UTC so offset from local wall clock is always well known and precisely defined. This make keeping additional explicit time zone information redundant. FAT keeps timestamps as local wall clock, this makes it impossible to compare with other timestamps if you do not know where those time stamps were created. There is no common scale. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2015-05-28 15:35, Andrei Borzenkov wrote:
On Thu, May 28, 2015 at 4:25 PM, Carlos E. R. <> wrote:
Actually, the timestamp problem with FAT is not that it does not store timezone information, because (I have just realized) Linux filesystems don't, as well.
They do. Timestamp is stored in UTC so offset from local wall clock is always well known and precisely defined. This make keeping additional explicit time zone information redundant.
You misunderstand. I mean that the filesystem does not store the *timezone* that applies to the timestamp. In Linux, the system knows that all timestamps are UTC (actually lapse to the epoch or whatever), and make a calculation to show the proper local time when displayed. There is no uncertainty. In msdos/windows (fat), they _assume_ all timestamps are local, and as the timezone is not recorded, there is no accurate way of knowing exact file time.
FAT keeps timestamps as local wall clock, this makes it impossible to compare with other timestamps if you do not know where those time stamps were created. There is no common scale.
Right. We are saying the same thing :-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 05/28/2015 09:35 AM, Andrei Borzenkov wrote:
On Thu, May 28, 2015 at 4:25 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
Actually, the timestamp problem with FAT is not that it does not store timezone information, because (I have just realized) Linux filesystems don't, as well.
They do. Timestamp is stored in UTC so offset from local wall clock is always well known and precisely defined.
What Carlos is saying is that the offset is not stored in the file systems that are 'native' to Linux. The offset is in the machine. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/28/2015 09:25 AM, Carlos E. R. wrote:
Thus I understand that cameras, or some cameras, actually use UTC internally.
Maybe. Mine don't, but that may be a function of when they were manufactured. I _could_ set the internal time to UTC. But I like to have local time on the screen :-) However, as I said, my cameras have GPS/geolocation capability so part of the exif is the satellite's UTC time. One supposes that can suffice :-) -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-05-28 16:04, Anton Aylward wrote:
On 05/28/2015 09:25 AM, Carlos E. R. wrote:
Thus I understand that cameras, or some cameras, actually use UTC internally.
Maybe. Mine don't, but that may be a function of when they were manufactured.
I _could_ set the internal time to UTC. But I like to have local time on the screen :-)
I don't know about mine. It has a clock, not GPS nor wifi, and it asks for timezone and summer/winter (it doesn't change automatically). But I don't know what it actually writes on the filesystem, and I'm not sure how to check it.
However, as I said, my cameras have GPS/geolocation capability so part of the exif is the satellite's UTC time.
One supposes that can suffice :-)
Yes :-) Accurate and reliable - provided you give time to the gps chips to sync. It may be minutes! At least my car navigator some times takes minutes to sync. Usually about 15 seconds. Sometimes I try to send a GPS fix from my phone, hit send too early, and it sends the last fix that can be 30 Km away, not the current, because it had no time to sync. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlVnJ+kACgkQja8UbcUWM1xtiwD8Dgn/65CP1kuDn7HwIQwTpaU+ ewnW66V2p0k4n8ikY34BAImWwHrno3kJfHGVBCKinmy8QIpK2qx0LTK3BcU9DKsc =MprJ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/28/2015 10:36 AM, Carlos E. R. wrote:
However, as I said, my cameras have GPS/geolocation capability so part of the exif is the satellite's UTC time.
One supposes that can suffice :-) Yes :-)
As they say, YMMV. With my camera it has problems getting a GPS "indoors", even in a wood-frame cottage/bungalow. I don't expect it to in a steel-frame +concrete-rebar building. The camera GPS also eats battery! But my phone is another matter. Light on the battery and i leave GPS on all the time, but it still lasts all day. My tablet, ditto, lasts 3 or 4 days. Better chip sets? Probably. The phone even picks up GPS in some office buildings and condos, though not in the downtown core with the jungle of adjacent hi-rises. The tablet is very good at picking up GPS. -- Excellence is an art won by training and habituation. We do not act rightly because we have virtue or excellence, but we rather have those because we have acted rightly. We are what we repeatedly do. Excellence, then, is not an act, but a habit. -- Aristotle -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2015-05-28 18:07, Anton Aylward wrote:
On 05/28/2015 10:36 AM, Carlos E. R. wrote:
But my phone is another matter. Light on the battery and i leave GPS on all the time, but it still lasts all day. My tablet, ditto, lasts 3 or 4 days. Better chip sets? Probably.
That it doesn't power the chip till a GPS fix is requested. If you use an application that tracks your location, or a navigation app, the battery also goes down fast, I'd bet. (When I go walking on the mountain I take an external battery pack in my rucksack - just in case) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 05/28/2015 01:45 PM, Carlos E. R. wrote:
On 2015-05-28 18:07, Anton Aylward wrote:
On 05/28/2015 10:36 AM, Carlos E. R. wrote: But my phone is another matter. Light on the battery and i leave GPS on all the time, but it still lasts all day. My tablet, ditto, lasts 3 or 4 days. Better chip sets? Probably. That it doesn't power the chip till a GPS fix is requested. If you use an application that tracks your location, or a navigation app, the battery also goes down fast, I'd bet.
Perhaps its model related. I tend to think so. My camera design is older than my phone and yes I do my one for even urban perambulations. This is a city of ravines and interconnected parks and while the major roads may be on a surveyor's measure grid[1], everything else is a maze of twisty turning passages that accommodate the 'green spaces' and what used to be the shorelines of Lake Iroquois http://en.wikipedia.org/wiki/Glacial_Lake_Iroquois and we have no shortage of "hilly rails" even within the city.
(When I go walking on the mountain I take an external battery pack in my rucksack - just in case)
A day out walking with "map on' and recording rates & route ... my stock battery lasts 4-6 hours. I do have a "hump-back" (double-plus) battery and back for when I feel paranoid or am vacationing, but it doesn't fit in any of my cases so I don't use it often. My tablet, which I use as a map when driving in unfamiliar areas (not least of all since many of my driving partners are not proficient map readers but seem to handle google-maps OK) seems to last a couple of days even with GPS on. And my tablet is a 'newer' design than my phone. All of which leaves me convinced it has to do with a level of technology used by the chip sets and not just the degree of usage. [1] Basically a mile and a quarter grid so that the land was parcelled up into 100 acre lots. In theory. In practice lakes, escapements and other 'natural features' got in the way, just as the Romans had found when they tried laying out 'straight line' roads centuries earlier. The mile and a quarter comes from the old "rod, pole, perch, chain" measure used by 17th and 18th century Brits. Since 1 statute mile is 8 Furlongs, 10 Furlongs make the mile and quarter of the "100 Acre" ... whoops! There goes Pooh Bear! No. Really. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2015-05-28 15:25, Carlos E. R. wrote:
On 2015-05-28 14:26, Anton Aylward wrote:
And according to this entry in the mount man page:
tz=UTC This option disables the conversion of timestamps between local time (as used by Windows on FAT) and UTC (which Linux uses internally). This is particularly useful when mounting devices (like digital cameras) that are set to UTC in order to avoid the pitfalls of local time.
Thus I understand that cameras, or some cameras, actually use UTC internally.
I tried this, comparing the file timestamp, both with and without that option, with the exif timestamps (there are several), and with the time I remembered a sample photo was taken. The file time was correct without TZ (and matched the exif stamps), incorrect with it. But I have not checked a photo taken in winter time, when the local time of the computer is summer, or the other way round. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
participants (9)
-
Andrei Borzenkov -
Anton Aylward -
Carlos E. R. -
Istvan Gabor -
James Knott -
John Andersen -
Patrick Shanahan -
Per Jessen -
Ted Byers