Remco Viëtor schrieb am 22.01.22 um 07:49:
On samedi 22 janvier 2022 07:28:57 CET Top Rock Photography wrote:
IF one's card is 32GB or less, it will not store time zone data, and that
may cause problems. If one does not have local time being kept correctly
by the OS, that may cause problems.
Am 22.01.2022 um 07:49 schrieb Remco Viëtor:
We also have metadata timestamps, generated by the camera. Most of these
shouldn't change. And afaik, Exif metadata couldn't store timezone as a
standard tag before 2016 (makernote is a different issue.
I'm getting a bit confused which of these
On samedi 22 janvier 2022 07:28:57 CET Top Rock Photography wrote:
> IF one's card is 32GB or less, it will not store time zone data, and that
> may cause problems. If one does not have local time being kept correctly
> by the OS, that may cause problems. If one's camera does not save local
> time
I think this is NOT a LInux issue (per se), and is MOSTLY a Nikon —and
perhaps other manufacturers— issue, with a bit of legacy DOS for good
measure.
With my Linux system, everything is chris & curry. Here is my exiftool grep.
«««
On 2022-01-20 3:16 p.m., Neal Holtz wrote:
2. Put something like this in /etc/fstab
LABEL=NIKON\040Dxxx /media/nholtz/NIKON_Dxxx exfat-fuse
user,noauto,tz=EST 0 2
I believe the tz setting should be whatever your camera is set to.
i'm not sure why this is required
Googling 'timestamp exfat linux' give you lots of rabbit holes
to run down ...
I got the following to sort of 'work' in my environment (Nikon + KDE Linux)
1. Install packages exfat-fuse, exfat-utils
2. Put something like this in /etc/fstab
LABEL=NIKON\040Dxxx /media/nholtz/NIKON_Dxxx
Did a check. On my camera the date and time is the same as on my
computer (give and take some seconds). The date/time of the file on my
camera is 1 hour later than the time in the EXIF. This is in the file
manager and in dt. Look here and see that there is the +0100 on the
date/time, the TZ
We are talking about the date/time that is shown in the copy
dialog, right?
I took a look in the source code. There is no exif magic. It's only the
file modification time that is used.
The timestamp is read from the file and assumed to be a local timestamp.
That will be converted according to
On Thu, 20 Jan 2022 16:53:14 +0100
Remco Viëtor wrote:
> Using UTC has at least the merit that it's a
> fairly neutral point, with no messing with
> DST and such. And if you ever need the local
> time, you can get the information needed for
> the correction.
It would be possible to do this
On jeudi 20 janvier 2022 14:41:47 CET Bernhard wrote:
> Remco Viëtor schrieb am 20.01.22 um 14:13:
> > I think the only solution for now would be to set your camera to UTC
> > (which
> > has disadvantages as well).
>
> That's what I am doing for years now.
> Imagine you are travelling along the
Remco Viëtor schrieb am 20.01.22 um 14:13:
I think the only solution for now would be to set your camera to UTC (which
has disadvantages as well).
That's what I am doing for years now.
Imagine you are travelling along the border Spain/Portugal or
Greece/Macedonia/Albania and go back and
On mercredi 19 janvier 2022 23:56:49 CET Bruce Williams wrote:
> OK, I think I understand what you said Nick. :)
> I also tried some of those ls switches on my own memory card and was able
> to replicate your results. Of course, mine are all +11, not -5, but that's
> to be expected.
> But where
On 20/1/22 10:20 am, Willy Williams wrote:
Bruce, I primarily use a Windoze machine on which the times match the
times on the camera body, including time zone. No problem with
darktable keeping the time straight. The same photos pulled into a
Ubuntu Linux machine again show the same time.
message -
From: *Neal Holtz*
Date: Thu, Jan 20, 2022 at 8:44 AM
Subject: Re: Fwd: [darktable-user] Timestamp oddity
To:
I have my camera (Nikon) set to EST (UTC-5).
Just took a photo at 2022-01-19 15:42 EST.
My computer displayed it as 10:42, not 15:42.
Timezone info is not recorded
, Jan 20, 2022 at 8:44 AM
Subject: Re: Fwd: [darktable-user] Timestamp oddity
To:
I have my camera (Nikon) set to EST (UTC-5).
Just took a photo at 2022-01-19 15:42 EST.
My computer displayed it as 10:42, not 15:42.
Timezone info is not recorded with the file time stamp.
So host computer has to assume
;http://soundcloud.com/audio2u> | Quora
<http://quora.com/profile/Bruce-Williams-5?share=1>
-- Forwarded message -
From: *Christian Birzer* <mailto:christ...@christianbirzer.de>>
Date: Thu, Jan 20, 2022 at 2:57 AM
Subject: Re: [darktable-user] Timestamp oddity
T
/audio2u> |
> LinkedIn <http://linkedin.com/in/bruce-williams-4893181/> | Facebook
> <http://facebook.com/audio2u> | Soundcloud <http://soundcloud.com/audio2u>
> | Quora <http://quora.com/profile/Bruce-Williams-5?share=1>
>
>
> -- Forw
On Wed, 19 Jan 2022 13:49:29 +0100
Marco DE BOOIJ wrote:
> Now that you mention, I have noticed the same
> thing. For me it is 1 hour difference.
Seems like at some point the time zone is not
being observed.
darktable
Now that you mention, I have noticed the same thing. For me it is 1 hour
difference. Could this have something to do with the regional settings
that are not taken into account in the "copy & import"? Since everyting
is correct after the import I did not pay attention to it anymore.
regards,
Hi all,
This evening, I was taking some test shots. The date/time in my camera IS
set correctly.
The time in the system tray (sorry to use the Windows name, but I assume
under linux, it's still called that?) of my Linux Mint is also displayed
correctly.
Yet, when I open the "copy and import"
20 matches
Mail list logo
