Incorrect date and time

[mathiasvr]

When I run Elodie on an image without Exif data, but with correct creation date and modification date, the file is copied such that the creation date and modification are changed to be exactly 1 hour before I ran elodie, this also affects the file name date which is 2 hour before.

Also, when I run it on an image with Exif data, it appears to work, but the creation and modification date are set to 1 hour before the date in Exif, and the filename is 1 hour before that (so 2 hours before the Exif date).

I'm not sure if this has something to do with timezones since I'm in UTC+2, but clearly, something isn't correct.

I'm using OS X 10.11.6.

[jmathai]

I believe this is a duplicate of #293.

There's an incomplete PR (#310) to use the timezone from EXIF location data.

Pls reopen if it's a different problem.

[mathiasvr]

I’m fine with the file name being UTC based on gps data, which works. But the modification and creation time is neither UTC or local time which is just weird? What is it then?

As for images without exif, the date and time is set to the current system time (-1 hour) which is obviously wrong. This means that all my images without exif basically has their time and date removed (set to current system time).

I don’t believe any of this is addressed in the issue and PR mentioned.

[jmathai]

To clarify, EXIF does not contain time zone information so it's not in UTC. Instead whatever offset there existed is lost. If I took the photo in UTC+7 then Elodie sees it at just UTC and loses the +7 [source].

That being said, the time used when a photo does not have EXIF should be the earlier of ctime and mtime on the photo [source]. If you're seeing something different then that's a bug. Could you confirm?

[mathiasvr]

Sorry if I'm explaining this poorly.
I understand that the Exif does not have time zone info, and the Exif date/time is usually local time of the photo.

First of all, Elodie renames my photos such that the date/time in the filename is 2 hours behind the Exif date.
This seems correct given the assumption that Elodie inferred that the Exif date was relative to my system timezone (UTC+2/CEST). Does Elodie do this or is this actually a bug?

If this is correct behavior, as I'm assuming, we can go back to the issues I described:

1. Images without Exif
   I can confirm that ctime and mtime of the file are not being used at all. Current system time is used for attributes and filename. I will try to investigate this further.

2. Images with Exif
   The filename is (correctly?) using UTC time of when the photo was taken, but the modification date is one hour ahead of that, and the Exif date/time is two hours ahead.
   I think I have tracked this down to be a daylight time savings issue, because Elodie always assumes no DST. I can provide further info if necessary.

I believe the desired behavior is to set modification date/time to the same as the filename (in UTC), so that in my case the date would appear two hours ahead, is this correct?

Again sorry if I'm not making any sense, but I am finding all this quite confusing myself.

[mathiasvr]

Okay, so I managed to debug the first issue (images without exif).
It seems that in the process_file function this code:

media.set_original_name()
metadata = media.get_metadata()

makes exiftool overwrite the source file, which then has it's modification time changed, and then afterward we get the metadata (with wrong modification time).

Maybe the problem can be solved by swapping these lines?

[jmathai]

Thanks for the explanation.

When no EXIF is available:
It's a little bit complicated when the date is not available in EXIF. So what we do is first get the last modified time before we make any changes [source] and then once we're done we set the modified time back to what it was before we did anything on the original and processed file [source].

On UNIX systems there's no record kept of when a file was created - only modified and accessed. It's there on Windows but we're not doing anything Windows-specific here.

That being said, I don't believe swapping the lines will help.

When EXIF is available:
The 2 hour delta for your time zone is the way Elodie is expected to behave. There's no single option that's obviously correct so we just use UTC as a neutral timezone. This way it's agnostic to the time zone your computer happens to be in or other factors.

#310 should address this though by applying the offset based off the location data in EXIF. I also added a todo on that PR to include tests to ensure it applies when updating the location of a photo or the date (i.e. changing the location of a photo should apply the appropriate timezone offset).

[jmathai]

Alright, turns out you were correct. Can you confirm if the fix in PR #331 addresses your issue?

I added a test and here's the failure and passing after a change.

Failure before change

(env) ➜  elodie git:(fix-dates) ✗ ./elodie/tests/run_tests.py elodie/tests/filesystem_test.py:test_process_file_no_exif_date_is_correct_gh_330
elodie.tests.filesystem_test.test_process_file_no_exif_date_is_correct_gh_330 ... FAIL 
======================================================================
FAIL: elodie.tests.filesystem_test.test_process_file_no_exif_date_is_correct_gh_330
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/jaisen/dev/elodie/env/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/Users/jaisen/dev/elodie/elodie/tests/filesystem_test.py", line 810, in test_process_file_no_exif_date_is_correct_gh_330
    assert '/2012-03-Mar/' in destination, destination
AssertionError: /var/folders/j9/h192v5v95gd_fhpv63qzyd1400d9ct/T/2019-07-Jul/Unknown Location/2019-07-27_06-47-28-photo.jpg

Passing after fix

(env) ➜  elodie git:(fix-dates) ✗ ./elodie/tests/run_tests.py elodie/tests/filesystem_test.py:test_process_file_no_exif_date_is_correct_gh_330
elodie.tests.filesystem_test.test_process_file_no_exif_date_is_correct_gh_330 ... ok

----------------------------------------------------------------------
Ran 1 test in 2.123s

OK

[mathiasvr]

Thanks for the quick response and fixes.

Yes, #331 fixes the first issue such that the modified date is taken into account.

However, the resulting image file still has a modified date that's 1 hour before the source image.
At least now both images with and without Exif are behaving in the same weird way, and the major problem I was having is fixed 👍

I have not looked over #310, but indeed considering location data would probably solve this and most timezone related problems.
For images without location data, I assume the current approach would be used and I still think there is a way to handle the date/time more consistently, but I'm fine with leaving this for now.

Edit: After examining this a bit more, I have opened a PR #332, which fixes my remaining issue.

[shivams]

@jmathai I think this issue needs to be re-opened.

I have a library of images which I had recently imported using elodie. The import went fine and there were no issues.

Now, when I started updating the location of those images, the images which did not have DateTime data in their Exif, were getting modified to the current timestamp (and losing their original timestamp). Fortunately, I had a backup.

To quickly reproduce the issue, you can try it out using a sample image:

mkdir elodie-testing; cd elodie-testing;
mkdir source destination
 #Download a sample image:
wget https://i.imgur.com/jGwDTpL.jpg -O source/image.jpg
#Its timestamp would be June 2017:
find . -type f -exec ls -l {} \;
 #Import would work fine:
elodie.py import --destination="destination" source
 #Check that the Timestamp was intact after import:
find . -type f -exec ls -l {} \;

#This will now mess up the timestamp:
elodie.py update --location "Bengaluru" destination/2017-06-Jun/Unknown\ Location/2017-06-27_00-31-20-image.jpg 
#You can now see that the timestamp has been modified to the current datetime
find . -type f -exec ls -l {} \;