-----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 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 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)

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

Andrei Borzenkov wrote:

On Thu, May 28, 2015 at 12:56 PM, Per Jessen 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 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 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: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

-----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

* Carlos E. R. [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

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

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

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 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 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: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

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 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