Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support time zone information in the createdate attribute in the index #7

Open
RKrahl opened this issue Mar 9, 2016 · 4 comments · May be fixed by #67
Open

Support time zone information in the createdate attribute in the index #7

RKrahl opened this issue Mar 9, 2016 · 4 comments · May be fixed by #67
Labels
enhancement New feature or request
Milestone

Comments

@RKrahl
Copy link
Owner

RKrahl commented Mar 9, 2016

When the index is created by photoidx create, the createdate attribute of the images is initialized from get_date_time() from the photo's exif data. But this yields a naive datetime object, without any time zone information. Should also try to get the time zone information from the exif data and set it in createdate.

However, I'm not sure if there is any standard exif field where this is stored. This might result in a vendor specific solution that only works for some camera models.

@RKrahl RKrahl added the enhancement New feature or request label Mar 9, 2016
@RKrahl RKrahl added this to the 0.4 milestone Mar 25, 2016
@RKrahl
Copy link
Owner Author

RKrahl commented Apr 9, 2016

Note that photo-tools relies on PyYAML for reading and writing index files. PyYAML does not handle time zone aware datetime values correctly, see this Issue in PyYAML.

@RKrahl RKrahl added wontfix This will not be worked on and removed priority medium labels Apr 10, 2016
@RKrahl RKrahl removed this from the 0.4 milestone Apr 10, 2016
@RKrahl
Copy link
Owner Author

RKrahl commented Apr 10, 2016

An attempt to implement this has been started in the timezone branch. But it turns out that there are a couple of problems:

  1. The location of time zone information in the exif data is vendor specific. I didn't found any comprehensive access method in GExiv2, though I might have overlooked something as GExiv2's documentation is sparse. So we would need to add every special case separately and still the feature would only work for a couple of particular models.
  2. We need an implementation of the datetime.tzinfo class to represent timezone aware datetime values. The standard library has datetime.timezone, but this has been added in Python 3.2 only. So either we would need add our own implementation or the feature would not work with Python 2.
  3. As mentioned in the last comment, PyYAML is not able to read time zone aware datetime values.

As a summary of all this, the problems seem to outweigh the benefits of this feature. I close as wontfix for the time being.

@RKrahl RKrahl closed this as completed Apr 10, 2016
@RKrahl
Copy link
Owner Author

RKrahl commented Nov 19, 2024

Reopen:

  • the need for datetime.tzinfo is not an issue any more, since we are requiring at least Python version 3.6 in the meanwhile,
  • PyYAML properly supports aware datetime values since version 5.3.

The remaining issue to be solved is to retrieve the time zone information from the exif data. But this could also be solved providing the information in command line argiuments.

@RKrahl RKrahl reopened this Nov 19, 2024
@RKrahl RKrahl removed the wontfix This will not be worked on label Nov 19, 2024
@RKrahl
Copy link
Owner Author

RKrahl commented Nov 19, 2024

Options to determine which time zone to set might include:

  • Getting them out of the exif data from the image. That would be the best option, but the info is hidden in vendor specific proprietary attributes, so this is not easy to implement and would only work for a few specific camera types.
  • Use the time offset between exif create date and GPS time stamp, assuming the latter to be UTC.
  • Use the current local time zone as set in the environment and assume the exif create date to be the local time in that zone.
  • Add a comand line argument to override the time zone.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant