Skip to content
This repository has been archived by the owner on May 3, 2021. It is now read-only.

[bug] Import of Pictures with DateTime 0000:00:00 fails #136

Closed
Schlump opened this issue Dec 3, 2018 · 5 comments
Closed

[bug] Import of Pictures with DateTime 0000:00:00 fails #136

Schlump opened this issue Dec 3, 2018 · 5 comments
Labels
bug Something isn't working Lychee-Laravel (version 4) This will be implemented in the Laravel version (Lychee 4).
Milestone

Comments

@Schlump
Copy link

Schlump commented Dec 3, 2018

Somehow i ended up with some pictures with a timestamp of 0000:00:00. Those images apparently can't be uploaded to lychee because column takestamp is set to dtype int. For a quick fix, i changed dtype in mysql db to bigint, but for longterm fix i guess parsing of the dates has to be changed.

Detailed description of the problem

Importing pictures with DateTime set to "0000:00:00 0000:00:00" in Exif tags fails because
MySQL db column for "takestamp" is set to int(11)

Steps to reproduce the issue

Upload Image with 0000:00:00 0000:00:00 in Exif tag

Output of the diagnostics (Settings => Diagnostics)

Error Code: 1264. Out of range value for column 'takestamp' at row 1

@ildyria ildyria added the bug Something isn't working label Dec 3, 2018
@bennettscience
Copy link
Contributor

Would an easy fix on this be to set the takestamp key as NULL if there is no date?

@ildyria
Copy link
Member

ildyria commented Dec 29, 2018

@bennettscience I'm actually considering switching the format of takestamp to timestamp instead of int().
The reason is to allow this searching by date with the help of eloquent and to solve issue #28 : https://laraveldaily.com/eloquent-date-filtering-wheredate-and-other-methods/

@ildyria ildyria added the Lychee-Laravel (version 4) This will be implemented in the Laravel version (Lychee 4). label Dec 29, 2018
@ildyria
Copy link
Member

ildyria commented Dec 30, 2018

0000:00:00 00:00:00 = -62169984000
So obviously this won't fit. 👍

@ildyria ildyria added this to the v3.2.9 milestone Dec 30, 2018
@usrecnik
Copy link

usrecnik commented Jan 2, 2019

It would still be possible that timestamp would be in year < 1970 or > 2038, right? Maybe range check should be added (or datatype of column changed)?

I made a quick (and possibly dirty) fix for release 3.2.8 (i'm not familiar with the source of this project), which is to add following code to Photo.php right after if statement in line 285:

            if ($info['takestamp'] > 2147483647 || $info['takestamp'] < -2147483647) {
                Log::notice(Database::get(), __METHOD__, __LINE__, 'takestamp=['.$info['takestamp'].'] is out of range, fixing it to 0.');
                $info['takestamp'] = 0;
            }

@ildyria
Copy link
Member

ildyria commented Jan 2, 2019

@usrecnik The datatype of the column is changed to

$table->timestamp('takestamp')->nullable();

and during the migrations, every dates will be converted:

$photo->takestamp = ($result->takestamp == 0 || $result->takestamp == null) ? null : date("Y-m-d H:i:s", $result->takestamp);

See here: https://github.com/LycheeOrg/Lychee-Laravel/blob/master/database/migrations/2018_08_15_103716_move_photos.php

Also you can make a PR with your dirty fix, at least this will solve the bug on Lychee. :)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working Lychee-Laravel (version 4) This will be implemented in the Laravel version (Lychee 4).
Projects
None yet
Development

No branches or pull requests

4 participants