When copying images (RAW format) from the memory card, using the “copy&import” option, Darktable changes the original date and time of the file (when the photo was taken), to the date and time of the moment the images are being imported into DT.
Any idea how to indicate to the program not to modify the date of the original file?
The curious thing is that when the photos are taken with the RAW+JPG option, the copied RAW files have their time and date modified, but not the JPG files.
This forces me into an unpleasant workflow: To use another program to copy the files from the memory card, and then import them into DT db.
What OS… WIndows?? Since the file is a copy it likely maybe shows date created on the media you transferred it to but this is not the date taken which will be in the metadata and unaltered… I don’t pull files off that way so I can’t speak from experience but raw files are never modified…
If in the lighttable you expand the image information module on the left side of the screen you will see an import time stamp and further down the list a datetime which is when the picture was captured. I am confident DT is not changing the datetime and you are being confused by the import timestamp. Good luck with solving this issue.
Thank you so much for your quick answers and comments:
This happens regardless of the version of DT or the version of windows (10 or 11), but always Windows.
Yes, certainly in the file properties in the left pane of DT it does recognize the original date. There is no problem there. The problem is in the date of the file itself after copying it.
I attach some screenshots…
This is on the memory card. The date and time are those of the moment the photo was taken:
… and this is the result on the destination folder:
EDIT: You can appreciate that the date of the JPG file has been preserved, but the date of the RAW file is changed to that of the moment it was transferred.
This does not happen when I use another program to copy the photos from the memory card and then import them with DT.
Thanks for your precise infos. so it’s not raw files that are modified but information of raw files creation in the hard disk. I never care or check that. Files are on my disk but I always check them with darktable. And as you said, darktable show the correct date.
I check on my system and indeed, date creation (I’m on Linux) is not the date of the RAW files but the import date. I found that normal (but I can understand that it could be annoying for you) as this information is mainly system file information (and not file one: that info is on EXIF metadata inside the RAW). What’ is more strange is that the date taken in account is not the same between RAW and JPG. Maybe, you could open an issue on darktable Github with all infos you posted here, and especially your last comment with screenshots. It would be then good to ping @phweyland as he works a lot on this part.
As far as the file system is concerned, the raw file was created on the filesystem on your computer when you copied it over. This information is stores by computer’s file system, not actually in the raw file.
If you look in dt at the image information, you will see the raw file has the capture date stored in it’s own metadata.
Not sure why the jpeg date doesn’t change, but that’s on windows, not dt.
Could this be Win interpreting this as a file copy vs a move and so it provides the new date. I don’t use this feature in DT but I don’t think there is a move feature in the import dialog such that the the files are taken off the card is there?? As I said I don’t use it so this could be conjecture but maybe if that was an option…then Windows would use a move function and not change the date like it would for a copy. I think it wouldn’t be the safest way to go. I would rather see the transfer completed and confirm the files were transferred and then go and clean the card myself…
I am not so sure that it is a Windows problem, rather it shows that it is probably a DT issue when copying the raw file. But let’s wait and see what they tell me on Github.
I doubt what I am about to suggest would work, but you could try it. In preferences for the storage I tell DT to only create an XMP file after editing. I do this because I don’t see a purpose in creating an xmp file on import which is the default behaviour. I wonder if the creation of the xmp file would affect the date change, but since the JPG also gets an xmp file I doubt this is the issue. Good luck resolving this. I had never noticed this issue before because I sort my pictures into date folders at time of import.
I don’t see any problem at all and would stick with Mica. These informations are stored by Windows in the filesystem and aren’t related to any raw data.
There are more rows you could enable in the explorer. One of them is “Date of capturing” (or rather Date taken, thanks to priort [ fecha de la toma]) and should be the only one that actually fetches its data from the raw.
It comes out in English as Date Taken at least for windows… On my phone now but if I recall there are maybe 4 or 5 date related fields you could add to explorer if needed…
