Closed (cannot reproduce)
Project:
Exif
Version:
7.x-1.x-dev
Component:
Code
Priority:
Major
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
27 Dec 2009 at 17:41 UTC
Updated:
13 Nov 2017 at 11:23 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
asb commentedAnyone?
This might be a related issue: #259308: Allow "fuzzy" granularity. The problem might be caused by trying to write the EXIF date data into an CCK date field (
field_exif_datetimeoriginal,field_exif_datetimedigitized).If extracting the data into a text field, I'm getting more reasonable results. The backside of using text fields is that they can't be used as flexible as a date field (e.g. for builing views based on date and time information). To be more precise, using CCK text fields has very little advantages compared to simply printing selected EXIF data (like the old 'exif' module (5.x) did. Text fields are quite useless for calculations or sorting, and they can't be formatted nicely; date strings like
Date the picture was taken: 2009:04:29 11:01:38are less than user friendly.Also, EXIF seems not to store the data data in the format
2006-12-04T00:00:00as documented at./admin/settings/exif/general. When extracting an unparsed text string from EXIF, I'm getting something like this:2010:02:20 11:45:38. Also, the latter one matches the EXIF 2.2 documentation (available from exif.org).However, using a user defined CCK date field, named
field_ifd0_datetimeorfield_exif_datetimeand formattedY:m:d H:i:salso fails to extract correct dates/times.Greetings, -asb
Comment #2
asb commentedI did some more trial & error "research" on this.
The CCK date module offers three date fields (documentation for Date 2.0):
Whatever type of date field I'm using, and whatever EXIF date the image has stored, the 'exif' module always extracts the string "Freitag, 1. Januar 2010 (All day)" (with or without the "All day" string).
Setting of the CCK field: Widget: "Text field with user defined input format"; Default value "empty"; "To-date": "empty"; "User defined input format: "Y:m:d H:i:s"; Number of values: "1"; "To-date: "never"; granularity: "Year, month, day, hour, minute, second"; Time zone handling: "none".
Setting this to critical since I've tried everything reasonable without getting correct results.
Greetings, -asb
Comment #3
rapsli commentedlooks the same: http://drupal.org/node/726738
Comment #4
jessia commentedYeah... I've got the same issue. 1 Jan 2010 for all dates.
Comment #5
rapsli commentedsorry, I could not reproduce this bug. Here's what I did:
took a datetime field, name: field_exif_datetimeoriginal ... didn't do any configuration -> worked.
Comment #6
rapsli commentedcan anybody tell me how to reproduce this bug?
Comment #7
asb commentedNot really, sorry.
My current configuration:
If I'm using one of the CCK date field types described in #2 with the same field names, I'm getting those "January 1st 2010" dates in all three fields - at least that was the behaviour before I switched to text fields a couple of weeks ago. It's a bit hard to continue experimenting with this since only one field with the name "field_exif_datetimeoriginal" is allowed. If time permits I'll set up a sandbox for this.
Greetings, -asb
Comment #8
rolfmeijer commentedCould also be a bug in the Date module, see #798244: Custom input format in admin/content/node-type/*/fields/field_* broken. Choose date from popup, always set to now.
Comment #9
asb commented@rolfmeijer: Doesn't sound unlikely, but the mentioned issue is closed.
Was anyone ever able to exctract EXIF data into a date field? If not, I'd go for a dumb text field after hoping for a fix or workaround for almost two years...
Comment #10
Anonymous (not verified) commentedHere's how to reproduce:
Hopefully these instructions will help to get this issue fixed.
Comment #11
Anonymous (not verified) commentedOk, I've worked out that the issue lies with this code (line 237 of exif.module):
$date_datetime = new DateObject($exif_value,NULL, $format);If I put
dpm($date_datetime);immediately after it and re-save my article node, it displays a DateObject that includes an error saying:The value 2011-07-09T19:29:51 does not match the expected format.The DateObject also includes a 'date' string of
2011-10-01 00:50:12(which is the current date/time and which I'm assuming it does because of the error). This is obviously how the wrong dates are being displayed.I was able to fix this by commenting out the following code (lines 94-101 of exif.class.php):
This keeps the date in the original format of
YYYY-MM-DD HH:MM:SSinstead of adding the 'T' in the middle which seems to cause the error.I haven't made a patch as I'm not sure if this code affects other parts of the module... Please advise how best to fix this.
Comment #12
asb commented@BWPanda: Does your observations apply to the D6 version as well?
Comment #13
Anonymous (not verified) commentedNo, just D7... D6 might very well have the same problem/solution, but I haven't looked at it.
Comment #14
jphautin commentedComment #15
jphautin commentedHello,
Just a question before going into deeper analysis.
Have you try to change in the Date admin Page, the pattern of the 'date_format_exif' with/without the T ?
regards,
Comment #16
Anonymous (not verified) commentedI just tried changing the 'Exif' date format to one without the 'T', but it doesn't make any difference (I made sure I cleared the cache and re-saved the node after changing it).
Even changing the date to display in the 'Exif' format on the node's 'Manage Display' tab didn't work.
I then realised that just commenting out the last line of #11 above works, instead of commenting out the whole code block:
//$value = implode("T", $date_time);(i.e. comment out line 101 of exif.class.php to get dates working properly)
Comment #17
jphautin commentedThe date format to read was incorrect. Corrected in last head revision. All date should work fine.
Comment #18
asb commentedDoes this only apply to the 7.x-1.x-dev branch (to which this issue was changed in #10), or is this fixed in 6.x-1.x-dev as well?
Comment #19
jphautin commentedOn 7.x-1.x-dev, raspli is the only committer on the 6.x branch
Comment #20
asb commentedToo bad :-(
Comment #22
asb commentedNope, this is not fixed as the issue was originally filed against 6.x-1.2 and changed in #10 to 7.x-1.x-dev.
If the fixes don't make it into the 6.x-1.x branch, the issue is either still active, or it's yet another "won't fix".
Comment #23
Anonymous (not verified) commentedIn that case, I think the fix in 7.x simply needs to be backported to 6.x...
Comment #24
asb commentedYeah, that's even better, thanks. But even if someone does the backport, still nobody has committ access to the 6.x-1.x branch?
Comment #25
Anonymous (not verified) commentedI just came across this issue again when installing the latest stable version of EXIF on a new site.
The attached patch fixed it for me.
Comment #26
carolynmarenger commentedI am getting the same issue. The date loads correctly as a text field, with the 'T' between date and time. When I load it as a date field, it comes back with the current date and time.
Which date type am I supposed to use (Date, Unix date-Time stamp, or ISO date). Or do I need to wait until the fix comes out and/or figure out how to apply the patch?
Thanks, Carolyn
Comment #27
carolynmarenger commentedI just found the solution and it worked for me. I am copying it from another thread to hopefully make it easier for you to find.
Posted by alexh on January 25, 2012 at 7:22pm
Yes, I had the same issue and fixed it like this:
Checked the date format of sample data at admin/config/media/exif/general. It looks like 2006-12-04T17:27:44
Add format Y-m-d\TH:i:s at admin/config/regional/date-time/formats
Go to admin/config/regional/date-time and set the exif date type to that format.
Hope that helps.
Comment #28
shawn dearmond commentedMarking as duplicate of #668688: Dates extracted are incorrect
Comment #29
Anonymous (not verified) commentedLikely just a typo, but you shouldn't mark as issue as a duplicate of itself...
Comment #30
shawn dearmond commentedDoh! My bad!
I meant to mark the following one as a duplicate, but it's already been marked closed. Oh well.
#1191480: Date field format should match exif spec
Comment #31
jphautin commentedThis issue is on 7.x branch. Do you still have the issue on 6.x branch or 7.x ?
Comment #32
jphautin commentedComment #33
jphautin commentedComment #34
mariaioann commentedI had the same problem with Exif 7.x-1.8 (as described in #11) and the solution proposed in #27 has fixed it for me.