Date folders created using import are UTC based

[Matt & Lek]

I just found out that it works as you would expect for photos only; i.e.
the viewer shows the image date (not UTC) and the file was imported into
the correct directory.

4:18PM is correct to the local time and it is imported into the 09 folder.
The digiKam date is also correct.

[image: image.png]


For videos, it does that UTC thing. This was shot around the same time, but
the video file was imported into the 10 folder.

[image: image.png]


Matt


On Thu, Jan 4, 2024 at 9:51 AM Matt & Lek <st11x at yahoo.com> wrote:

> Thanks Maik.
>
> For me, because I'm in the UTC-8 timezone, all my photos and videos shot
> after 4pm or 5pm gets filed under the next day's folder and I have to move
> them back manually. I'll just have to live with this or write my own import
> script.
>
> Thanks
> Matt
>
> On Thursday, January 4, 2024 at 09:42:06 AM PST, Maik Qualmann <
> metzpinguin at gmail.com> wrote:
>
>
> The date  display in the thumbnail in the import window depends on whether
> you
> have activated the loading of the camera metadata in the digiKam camera
> settings, otherwise it is the file date. But it doesn't matter when
> downloading, since digiKam-8.0.0 the metadata has always been used. I
> tested
> it here with pictures before and after midnight, everything correct.
>
> Another note, the current digiKam-8.3.0 that is available for download
> still
> has a problem, if its file path contains non-ASCII characters, wait for
> the
> next version.
>
> Maik
>
> Am Donnerstag, 4. Januar 2024, 18:06:15 CET schrieb Matt & Lek:
> >  Thank you, I downloaded that version and I suppose the fix was to make
> > everything show UTC? I see that the timestamp in the viewer shows the UTC
> > date instead of the file date, I thought it was showing the file date
> > before.
> >
> > However, in the import window below, it still shows the file date
> although
> > it is slightly off by 2 minutes.
> >
> > For me in this timezone, all my evening shots will be imported filed
> under
> > the next day's date during the automatic import which is not ideal.
> >
> > ThanksMatt
> >
> >
> >
> >
> >    On Thursday, January 4, 2024 at 08:45:33 AM PST, Gilles Caulier
> > <caulier.gilles at gmail.com> wrote:
> >
> >  Hi,
> >
> > 8.3.0 pre-release bundles are there :
> >
> > https://files.kde.org/digikam/
> >
> > Best
> >
> > Gilles Caulier
> >
> > Le jeu. 4 janv. 2024 à 17:34, Matt & Lek <st11x at yahoo.com> a écrit :
> > > Hi Maik,
> > >
> > > Where do you get version 8.3.0? Yes I am using the Windows version, the
> > > one tar ball version. I see the documentation saying 8.3.0 but when you
> > > go to the download page https://www.digikam.org/download/, the latest
> > > version is 8.2.0.
> > >
> > >
> > > thanks
> > >
> > >  Matt
> > >
> > > On Wednesday, January 3, 2024 at 11:08:16 PM PST, Maik Qualmann
> > > <metzpinguin at gmail.com> wrote:
> > >
> > >
> > > This problem should already be fixed in digiKam-8.3.0. I assume you are
> > > using the Windows version. By switching from Qt5 to Qt6 there are some
> > > unexpected date conversions to local time. We therefore switched
> > > internally to a UTC date format in digiKam-8.3.0, also because of a
> > > massive performance problem under Windows regarding the local time
> > > format.
> > >
> > > Maik
> > >
> > > Am Donnerstag, 4. Januar 2024, 02:05:18 CET schrieb Matt & Lek:
> > > > Hi,
> > > > I am importing images from the SD card and have used the custom date
> > > > option
> > > > with this simple value : yyyy/MM/dd
> > > >
> > > >
> > > >
> > > > when the files are imported, I suspect the folder created is based on
> > > > the
> > > > UTC date.
> > > >
> > > > In this example, the image was filed under 2024 even though the image
> > > > has a
> > > > 2023 created date. Is there a way to change this? thanks  Matt
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20240104/b7483e1f/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 57329 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20240104/b7483e1f/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 61401 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20240104/b7483e1f/attachment-0003.png>