Jump to content
You must now use your email address to sign in [click for more info] ×

Issue with daylight savings time metadata and Google Photos


Recommended Posts

The basics:

Affinity Photo v. 1.10, Windows 10 Home.

I'll note here too that I have a Nikon camera in which there is a "daylight savings time" function that one activates when it comes around. So, in my camera, when daylight savings time becomes active, I don't change the time in my camera, I just change the daylight savings time function to "Yes" and the camera corrects the time automatically.

Recipe for the issue:

1) Go take pictures in Winter (so no daylight saving time).

2) While still in winter, process the pictures in Affinity Photo, or a combination of AP, and, say, some other raw developer (in my case, RawTherapee).

3) Upload them to a Google Photos Album and organize the Album by "Oldest first". Everything falls into place nicely and all the photos will show the correct date and time, and the correct time zone, i.e. "GMT+01:00 Central European Time" (thus, "normal time") in my case, when you open the Info function of Google Photos.

4) Wait until summer then open one of your winter photos in AP and reprocess it for X reason and resave the image.

5) Re-upload the new version to the Google Photos Album above: the photo will be out of place. Look at the Info of the photo. The date and time will not have changed, but the time zone will be changed to "GMT+02:00 Central European Summer Time" (thus, "daylight savings time").

6) Get frustrated, because that photo was not taken during daylight savings time, and now you have to fix the time zone and time data in Google Photos.

The same thing happens in the other direction: a photo taken in summer but reworked in winter will be given the "normal time" although it was taken in "daylight savings time".

HOWEVER, and here's the weird part: This problem does not manifest on my PC (neither in XnView MP (my main photo browsing app) nor in Window Explorer.

Is this Affinity Photo's fault?

I don't know, but here's what I can say:

I do not encounter this problem for photos that do not pass through AP. For example, a photo taken and initially processed in winter only in RawTherapee (or not processed at all) will, like above, show the correct "GMT+01:00 Central European Time" in the initial upload to Google Photos. Should that photo be reprocessed in summer, again only in RawTherapee, then uploaded again to Google Photos, this new version will still have the correct "GMT+01:00 Central European Time" associated with it.

I have not tested this phenomenon in any other photo editing software.

So what's happening exactly here I do not know. Is AP perhaps changing how daylight savings time metadata is written to a form known by Windows and Co. but not by Google Photos (this latter resultantly defaulting to the present one)? Pure speculation on my part...

Thanks for hearing me out, and if anybody else has encountered this, feel free to sound in.

Happy shooting to all!

 

 

 

Link to comment
Share on other sites

Extra information for the above:

Having just run into this again, I used the ExifTool function built into XnView MP to compare the metadata of files that I readjusted recently (thus during "normal time") and that were, or were not, affected by the above.

All concerned images were taken during the summer (thus during "daylight savings time").

Those that went through Affinity Photo, and thus were affected by the above, have, in the XMP metadata, a "Modify date" and a "Metadata date" with "+01:00" affixed to the end of the data thread. Here's an example of what this looks like: "Metadata Date      2021:11:29 18:50:38+01:00". EDIT: this is the time at which I reprocessed the image.    

Those that did not go through Affinity Photo, and thus were not affected by the above, do not have these lines in the XMP metadata.

Of course, all of the files have, in the File metadata, "File modification", "File Access" and "File Creation" dates and times with the "+01:00" affix, which is normal as they were all modified over the last few days.

I hope this extra information can be of use. Again, I don't know if this is truly a bug with Affinity Photo, but I figure that you would at least like to know that there's a compatibility issue between AP and a major online photo storing application, even if this latter might be the one doing weird stuff.

Thank again.

 

Link to comment
Share on other sites

  • Staff

Hi @Kerwin,

Thanks for your report!

I've been able to replicate this behaviour here, it's almost certainly due to the 'Metadata Date' tag in the file - however this is the correct tag to be used by Affinity when writing the file and therefore I believe this to be an issue with how Google Photos is reading the data, rather than how Affinity is writing it.

I've found the following site, along with a few other reports of users reporting similar issues with Google Photos -

https://medium.com/@nontavit/google-photos-and-time-zone-issue-b2e2d20645b0

Interestingly, the above link confirms the following:

Quote

If GPS Coordinates is NOT presented, Google Photos will assume that the photo is taken in uploaded time zone/location (which is determine by your internet connection IP — you can’t just change Windows timezone setting to fool them)
In this case, if you took photo in GMT+1 and upload in GMT+7. All photo will be treat as they were taken in GMT+7.
Example, photo taken at 10 AM GMT+1, upload in GMT+7. Google will treat that the photo is taken at 10 AM GMT+7 — equal to 4AM GMT+1.

Which could explain what you're seeing, that Google Photos is using your current time zone when uploading, rather than the images metadata at all - however that doesn't cover the images that have been edited in RawTherapee and re-uploaded to Google Photos that don't exhibit this issue.

I'm going to log this with our developers now, not explicitly as a bug - as I have mentioned I believe Affinity is using the correct tags and they are being incorrectly interpreted by Google Photos - but as a suggestion to allow an export option that does not write this 'Metadata Date' tag, such that Google should continue to read the metadata correctly.

If you're willing to, have you tried editing the metadata to remove this tag and re-upload the image to Google Photos? I would be interested to know if our assumptions are correct, as I cannot see any other metadata changing between edits on my end :)

Please note -

I am currently out of the office for a short while whilst recovering from surgery (nothing serious!), therefore will not be available on the Forums during this time.

Should you require a response from the team in a thread I have previously replied in - please Create a New Thread and our team will be sure to reply as soon as possible.

Many thanks!

Link to comment
Share on other sites

Hi Dan C,

Thank you for this confirmation.

Indeed since this doesn't happen to photos without the XMP metadata dates, I too deduct that it isn't Google defaulting to the current timezone info but rather misusing the metadata.

As for deleting the XMP metadata dates and retesting, uhm, errrr, well, I'll have to figure out how to do that with exiftool (which I only use in a consultative fashion), but yes, I'll give that a try and report back.

Thanks again and happy shooting!

 

Link to comment
Share on other sites

Reporting back on the idea of deleting the metadata under discussion.

I need to note here that there was a third line in the XMP metadata that I hadn't noticed before, labelled "History When" in photos affected by the problem presented here. So we actually have three potential problem lines in the XMP metadata:

  • "Metadata Date"
  • "History When"
  • "Modify date"

So, I made a copy of one of the images affected by the issue discussed above (in this case, a photo taken in summer but reprocessed in winter), and deleted the "Metadata Date" line using ExifToolGUI, and re-uploaded it to Google Photos. This first test photo remained affected by the problem, that is, it was out of place, because it had the "GMT+01:00" descriptor in a series of photos of "GMT+02:00" images. Remember that this first copy still had the "History When" and "Modify Date" lines (with the "+01:00" affix) in the XMP metadata.

I then made a copy of the copy (thus with "Metadata Date" already deleted), and deleted the "History when" line and uploaded it to Google Photos. This second test photo too remained affected by the problem.

I thereafter made a copy of the copy of the copy (thus with with "Metadata Date" and "History When" already deleted) with the intention of deleting the "Modify Date" line in the XMP metadata. But that proved a bit more difficult, because there is also a "Modify Date" line in, for example, the EXIF group, and I didn't want to delete both of those lines. So, I just used the ExifToolGUI's built-in "Remove metadata" function to delete all of the XMP metadata (but no other metadata). I thereafter uploaded this third copy to Google Photos, and this third test photo was unaffected by the problem. It went right where it belonged and showed the correct "GMT+02:00" affix on the date and time in the Google Photos info.

Ideally of course, I would have liked to delete just the "Modify Date" line in the XMP metadata, for this third copy but I note that in those XMP metadata, only these three lines, "Metadata date", "History When"  and "Modify Date" show the date and time at which the photo had been re-processed (in winter), with the "+01:00" affix.

The only other date mentioned in the XMP metadata is "Create Date", which gives the date and time at which the photo was actually taken (in summer), and it does not have a time zone affix.

So, we now know that deleting "Metadata Date" alone does not fix the problem. We know that deleting "Metadata Date" and "History When" does not fix the problem. We also know that deleting all three lines does fix the problem. What is left unknown, is whether deleting "History When" alone or deleting "Modify Date" alone would fix the problem... But I don't have the energy to go on!

Hope all this helps, and I'm gonna step away from the computer now.

Link to comment
Share on other sites

  • Staff

Apologies for the delayed response here as I have been out of the office until today - many, many thanks for the further information and tests conducted here, it's certainly helpful information that I am currently passing through to our developers, to see if we can improve this in a future update :D

Please note -

I am currently out of the office for a short while whilst recovering from surgery (nothing serious!), therefore will not be available on the Forums during this time.

Should you require a response from the team in a thread I have previously replied in - please Create a New Thread and our team will be sure to reply as soon as possible.

Many thanks!

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.