@Sannita I can't reproduce this. If I download the image the user had trouble with, rotate it, and re-upload it (without publishing) then the date field gets populated from the EXIF as expected

Maybe the user could give us another image of theirs that hasn't been uploaded and we can try with that?

I still have the issue.

Are you uploading these are your own work, or as someone else's?

Using “This is someone else's work and is free to share” and “Enter a different license in wikitext format”, so I can use {{Not public domain|license=by-sa|version=3.0/au|author=Robert Myers}} {{self|cc-by-sa-3.0-au|attribution=Robert Myers ([https://creativecommons.org/licenses/by-sa/3.0/au/deed.en CC-BY-SA 3.0 AU])}}

I can replicate it on my iPhone (screenshot attached), MacBook and Windows PC.

Aha, ok! I thought maybe you were Robert Myers IRL ... this was actually a deliberate choice on our part, because images uploaded under "this is someone else's work and is free to share" can be scans and downloads and sometimes the EXIF date doesn't mean what we expect it to mean. Let me bring it back to the team ...

Any update? I’m not going to do any uploading if I have to keep manually adding the date.

We have this ticket to allow users to add custom licences for their own work, so that should cover you I think? https://phabricator.wikimedia.org/T366501

But what would the timeline for that be? Weeks? Months? Never?

For "this is someone else's work and is free to share", rather than disabling EXIF for all files, do it for select file types (svg, png, tif ect) but allow jpg and have some sort of dialogue with “Is this correct” or something similar.

Weeks, most likely. It's part of our work for this quarter

If T366501 covers your use-case then I'm gonna close this one - that ok?