Hi,

I noticed that the module seems to extract dates incorrectly (e.g. Thursday, 1. January 2009 - 1:00 instead of 12th of April 2009).

Before staring to dig in the EXIF data and the CCK field configuration - does this work well for other users, or is this part of the module maybe simply not yet ready for everyday use?

Thanks & Greetings, -asb

CommentFileSizeAuthor
#25 Incorrect_dates-668688-25.patch358 bytesAnonymous (not verified)

Comments

asb’s picture

Priority: Critical » Normal

Anyone?

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:38 are less than user friendly.

Also, EXIF seems not to store the data data in the format 2006-12-04T00:00:00 as 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_datetime or field_exif_datetime and formatted Y:m:d H:i:s also fails to extract correct dates/times.

Greetings, -asb

asb’s picture

Priority: Normal » Critical

I did some more trial & error "research" on this.

The CCK date module offers three date fields (documentation for Date 2.0):

  • Datestamp (Unix Timestamp) - Stores the date as an integer; we can't use this
  • Date (ISO Date) - Stores the date in an ISO format (YYYY-MM-DDTHH:MM:SS); appears to me as the reasonable choice, but seems not to work at all (as described in #1)
  • Datetime - Stores the date in the database's native date format (YYYY-MM-DD HH:MM:SS); also tried this, doesn't work either

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

rapsli’s picture

Priority: Normal » Critical
jessia’s picture

Yeah... I've got the same issue. 1 Jan 2010 for all dates.

rapsli’s picture

sorry, 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.

rapsli’s picture

Status: Active » Postponed (maintainer needs more info)

can anybody tell me how to reproduce this bug?

asb’s picture

Not really, sorry.

My current configuration:

  • field_exif_datetimeoriginal - extracts 2010:02:16 09:52:29 into a CCK text field
  • field_exif_datetimedigitized - extracts 2010:02:16 09:52:29 into a CCK text field
  • field_ifd0_datetime - extracts 2010:02:16 09:52:29 into a CCK text field

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

asb’s picture

Priority: Critical » Major
Status: Postponed (maintainer needs more info) » Active

@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...

Anonymous’s picture

Version: 6.x-1.2 » 7.x-1.x-dev

Here's how to reproduce:

  • Setup Exif (7.x-1.x) and Date (7.x-2.0-alpha4) modules on test site
  • Add following field to Article content type:
    • Label: Date Taken
    • Name: field_date_taken
    • Field: Date
    • Widget: metadata from image
    • exif field data: exif_datetimeoriginal
    • Default date: No default value
    • Date attributes to collect: All (year, month, day, hour, minute, second)
    • Collect an end date: No (unchecked)
    • Time zone handling: No time zone conversion
    • (all other values as default)
  • Select an image to test, copy it to Exif module directory and rename to 'sample.jpg'
  • Go to http://example.com/admin/config/media/exif, make sure the test image's thumbnail is displayed on the right, then scroll down to the 'exif' section and note the 'field_exif_datetimeoriginal' value (mine is: 2011-07-09T19:29:51)
  • Create a new 'article' node, upload the test image and save
  • Note the value of the 'Date Taken' field (mine is: Friday, 30 September 2011 - 6:29pm) - doesn't match previously noted value

Hopefully these instructions will help to get this issue fixed.

Anonymous’s picture

Ok, 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):

// In case we get a datefield, we need to reformat it to the ISO 8601 standard:
// which will look something like 2004-02-12T15:19:21
$date_time = explode(" ", $value);
$date_time[0] = str_replace(":", "-", $date_time[0]);
if (variable_get('exif_granularity', 0) == 1) {
  $date_time[1] = "00:00:00";
}
$value = implode("T", $date_time);

This keeps the date in the original format of YYYY-MM-DD HH:MM:SS instead 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.

asb’s picture

@BWPanda: Does your observations apply to the D6 version as well?

Anonymous’s picture

No, just D7... D6 might very well have the same problem/solution, but I haven't looked at it.

jphautin’s picture

Assigned: Unassigned » jphautin
jphautin’s picture

Hello,

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,

Anonymous’s picture

I 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)

jphautin’s picture

Status: Active » Fixed

The date format to read was incorrect. Corrected in last head revision. All date should work fine.

asb’s picture

Does 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?

jphautin’s picture

On 7.x-1.x-dev, raspli is the only committer on the 6.x branch

asb’s picture

Too bad :-(

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

asb’s picture

Status: Closed (fixed) » Active

Nope, 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".

Anonymous’s picture

Version: 7.x-1.x-dev » 6.x-1.x-dev
Assigned: jphautin » Unassigned
Status: Active » Patch (to be ported)

In that case, I think the fix in 7.x simply needs to be backported to 6.x...

asb’s picture

Yeah, that's even better, thanks. But even if someone does the backport, still nobody has committ access to the 6.x-1.x branch?

Anonymous’s picture

Version: 6.x-1.x-dev » 7.x-1.x-dev
Status: Patch (to be ported) » Needs review
StatusFileSize
new358 bytes

I 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.

carolynmarenger’s picture

I 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

carolynmarenger’s picture

I 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.

shawn dearmond’s picture

Status: Needs review » Closed (duplicate)
Anonymous’s picture

Status: Closed (duplicate) » Needs review

Likely just a typo, but you shouldn't mark as issue as a duplicate of itself...

shawn dearmond’s picture

Doh! 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

jphautin’s picture

This issue is on 7.x branch. Do you still have the issue on 6.x branch or 7.x ?

jphautin’s picture

Status: Needs review » Postponed (maintainer needs more info)
jphautin’s picture

Issue summary: View changes
Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)
mariaioann’s picture

I 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.