wp_read_image_metadata should look for timezone offset

[dshanske]

Related: #49413

This function should look for where cell phones and cameras store timezone offset data.

Storing the time as a timestamp is a mistake as the time in exif data is minus the timezone and in whatever time the device was set to, it would have been better to store as a formatted time as converting to timezone means that everything is off.

EXIF supports storing timezone offset in several places, if there we should use it, otherwise assume site timezone.

[Rarst]

I'll grab this into Date/Time as well, sounds like my domain. :)

[dshanske]

As part of this, I haveto ask the question...are we safe to assume more and more people are uploading pictures taken with smartphones over digital cameras? If so, then the metadata preferences should probably change priority based on the likely properties of an image uploaded from one of these while not ignoring the fact there are still many hobbyists with digital SLRs

[joemcgill]

Hi @dshanske, I'm unclear on what exactly you are proposing here? Are you proposing that we change the data format that we are returning for created_timestamp, are you suggesting that we return additional metadata, or are you suggesting something else?

[dshanske]

@joemcgill Well, timestamp has a specific meaning... but the timestamp is always incorrect because it is converted incorrectly...which is a matter for the related ticket to improve the conversion function. I proposed there that it have an extra argument for the timezone offset, which means the image read function has to search for it more effectively.

Since someone answered the Exif question in that ticket, where I intended on it only being for modifying the function signature, I answered there.

Newer exif versions allow for a timezone offset. If that property is there, which I confirmed is readable by exif in PHP, then we should pass it along and use it to generate the timestamp if we want to keep this for backcompat

Secondly, exif has multiple date properties...we are using DateDigitized and storing it as the creation date..however exif has a file creation date, the date of the original, and the date it was digitized.

DateDigitized is not creation, so we are already misleading in the name of the property.

In a digital camera photo, original and digital date are the same...we should be therefore using original date unless blank, in which case, digitized date. If both are blank, I would give up.

Now we get to the fact that the timestamp is wrong due lack of timezone offset, we should check for the newer offset fields.. if not present, we can derive the timezone and adjust the timestamp appropriately by comparing the timestamp to the gps timestamp property, as that is in UTC.

If the offset cannot be derived from the GPS, if not available, then the time should assume to be in the site timezone.

I would also suggest that, if we are willing to deprecate storing the timestamp and maybe even if not, we should store the date in a iso8601 format, which allows for no timezone or timezone in the string

I care a lot more about when I took a picture then when I uploaded it, which currently displays prominently.

[dshanske]

Also, want to cite #14137, which discussed the fact we use only one of several timestamps to generate created. Didn't find this during my original search, but that was discussing a similar issue of what is used, whereas my point here is the property we are storing is not useful