XYplorer Beta Club

I took the decision to install the 64-bit version and did it 2 days ago. Today, I find the first annoying mistake:

Datei speziell > Änderungsdatum auf EXIF setzen
goes wrong for .CR2 files, with exchange of day <> month in the date -> see screenshot 'EXIF_Fehler V28.30.0100.jpg' [German - US confusion when writing ? reading seems OK, the time is written correctly]

The same for
Datei speziell > Erstelldatum auf EXIF setzen

For JPGs, all is OK


32 bit v27.20.1500 doesn't make this mistake, so I will use this one again ...

Can you mail such a CR2 file to support?

I'm seeing something similar with EXIF data.

I have a workflow where I run images through an app which, unfortunately, does not preserve the EXIF data. But later on I need the Capture Time (aka Date Taken) to be in the image file's EXIF data so I can match it with the original file. So I'm evaluating whether XYplorer can do that for me.

So far it seems to be working ... I have imported an original file and its processed counterpart into Adobe Lightroom, and Lightroom thinks they have the same capture time. (At least, to the nearest second. I need to work out whether / how I can specify the timestamp I'm writing to the millisecond, as it is recorded in the original EXIF. But that's not critical right now.)

However, XYplorer seems to be confused as to whether EXIF dates should be interpreted as DD/MM/YYYY or MM/DD/YYYY.

See the attached screenshot. The JPG file is the original, and the Date Taken was 12th August. The TIF file is the one that's been processed, and I've used XYplorer to write the Date Taken into the EXIF data. When I look at the file properties individually, the two files both have the same Date Taken - and, as mentioned above, this is confirmed by Adobe Lightroom. But when I look at them in the XYplorer list view, they appear to be different. I don't understand how XYplorer can be reading two dates which are the same, but interesting interpreting one as DD/MM/YYYY and the other as MM/DD/YYYY.

Can you mail such a JPEG file to support?

admin wrote: ↑20 Aug 2026 16:02 Can you mail such a JPEG file to support?

Sorry, are you asking me, or are you asking @SL09 the creator of the original post?

I can, and will, mail one. It's an ordinary JPEG file straight out of a Canon camera.

I sent a link to Support, because the files are too large. Link to MS-Onedrive:
https://1drv.ms/f/c/06995a52749c96f0/Ig ... E?e=2gzKAh

Thanks y'all, I will check out the files tomorrow.

The 3 test files I got from you all look good here. Cannot see the bug: Locale: English (US). What's your locale?

PS: definition of the "Exif 0x0132 (DateTime)" custom column: return get("exif", 0x0132, <cc_item>);

admin wrote: ↑22 Aug 2026 17:58 The 3 test files I got from you all look good here. Cannot see the bug

The JPEG I sent you was straight out of the camera, so if you haven't manipulated it in any way then it's perhaps not surprising that it was OK. My troubles started when I tried to insert the Date Taken into the EXIF data of a TIFF file that didn't have any EXIF data. But you asked for a JPEG file, so I did. Would you like me to send you the TIFF file that displayed the anomalous date formatting?

XYplorer does not write EXIF, only read.

> XYplorer does not write EXIF, only read.
Yes, but ... It takes the date from EXIF ['DateTimeOriginal'] and sets
- the 'Date changed': Datei speziell > Änderungsdatum auf EXIF setzen
- the 'Date created': Datei speziell > Erstelldatum auf EXIF setzen
of The FILE !?
And there apparently happens a mistake: see my first screenshot 'EXIF_Fehler V28.30.0100.jpg'; the columns are Name - Attr - Grösse - Änderungsdatum - Erstelldatum. This is the situation after import with the Canon-Software. Canon sets the 'Erstelldatum' correctly. Then I always change the 'date changed' = Änderungsdatum to the EXIF value.

Here is the filelist of the 2 examples I uploaded on MS Drive, from the 32bit Version [same in 64bit]:
XYPl Dateiliste.jpg
For demonstration, I also changed the 'Erstelldatum' - same mistake "08.11.2026" instead of "11.08.2026".

... with .JPG s, there is no problem, I can change both dates back and forth, set to 'Jetzt' etc.

Wird wohl an der deutschen Locale liegen. Schau ich mir morgen an. Sollte kein großes Ding sein.

... das Datum ist jedenfalls in der Datei (Infos aus Windows-"Bordmitteln")