🌍
English
Pages: 1
Hello,
I would like to understand how the photo attribute "Date Created" is filled from the EXIF/IPTC fields at import time, and how it relates to sorting: When I look at the value of this field from a newly imported set of photos (uploaded via the standard web multi-upload tool), it looks like the attribute is filled with a TRUNCATED version of the date/time value of the EXIF field from the photo: If the photo has this EXIF Field:
Date/Time Created : 2017:04:01 10:02:10
The "Date Created" field displayed for this photo is then:
Created on Saturday 1 April 2017
(see photo example here: https://photos.garzon.fr/picture.php?/1 … tegory/243)
When I edit the properties of this photo, the value shown is "Saturday 1 April 2017 00:00", and the database content is:
MariaDB [piwigo]> select date_creation from piwigo_images where id in (10308) ; +---------------------+ | date_creation | +---------------------+ | 2017-04-01 00:00:00 | +---------------------+
the data format for this database field (piwigo.date_creation) is DATETIME, so why is the EXIF date/time truncated at import ? because currently, the chronological order of the photos in the album is not satisfactory, because all pictures taken the same day have the same value for the sorting criteria, which results in pictures NOT in the chronological order, when choosing the "Date created, old → new" sort order: The photos are grouped by day, but then within the day, the order is not guaranteed by hour/seconds...
If you look at my gallery/album, you will see that I had to put the default sort order to "Date Posted" to have the photos in chronological order. If you choose "Date Created" the order is messed up...
Why is the date created field truncated ? Is this a known bug or an issue with my environment (PHP, OS version or local/TZ, etc.) ?
Thank you in advance for your answers,
Piwigo version
Piwigo 2.8.6
Environment
Operating system: Linux
PHP: 5.4.16 (Show info) [2017-04-06 09:27:59]
MySQL: 5.5.50-MariaDB [2017-04-06 09:27:59]
Graphics Library: External ImageMagick 6.7.8-9
Database
10359 photos (first photo added on Friday 11 November 2011)
243 albums including 231 physical and 12 virtual (10347 associations)
404 tags (21662 associations)
3 users
0 groups
no rate
Offline
Hi,
since nobody answered my question, I took the matter in my own hand ;-) By adding some debugging code in admin/include/functions_metadata.php I managed to find the issue: I was using a wrong iptc mapping that was overloading the default EXIF mapping of the db field date_creation to DateTimeOriginal:
I had to comment the date_creation below in local/config/config.inc to fix the problem:
$conf['use_iptc_mapping'] = array( 'keywords' => '2#025', // 'date_creation' => '2#055', 'author' => '2#122', 'name' => '2#005', 'comment' => '2#120' );
The '2#055' IPTC field stores only the date, not the "date/time" of the moment when the photo was taken, and the "2017-MM-DD' value stored in it was replacing the "2017-MM-DD HH:mm:ss' extracted from the Exif fied...
As I realized by looking at the code, when both $conf['use_iptc'] and $conf['use_exif'] are true, the IPTC value takes precedence over the EXIF value when mapped to the same db field.
I introduced the problem some months ago when I started the IPTC mapping to map IPTC keywords to tags in Piwigo. Thanks to the batch manager, after fixing the configuration, I just had to synchronize again the metada to fix the creation_date db field of the photos that had the truncated date_creation.
Offline
Thank you for sharing this! I was also having sort problems and commenting out the `date creation` section as in your example solved it for me.
Offline
Pages: 1