Closed Offirmo closed 11 months ago
Thanks for reporting. What is the tag name for the date with the wrong time zone?
(Also, you may need to use your own instance with custom options if you donโt want backfilled timezones)
My app is trying a list of dates and trying to pick the most promising one. I need to dig a little bit to give you this info.
I'm very happy with backfilled timezones, the regression is going from Australia/Sydney
(correct) to UTC+10
(inferior)
I took a look at the attached file. UTC+10 is Australian Eastern Standard Time (AEST), which is the correct offset for July for Australia/Sydney
.
Out of an abundance of caution, I'm purposefully not back-filling ExifDateTime instances that already have a zone specified in their raw form. In this instance, they match, but the offset is actually more reliable than the zone, as the zone requires a context time to determine the final offset. The prior brute-override was arguably a bug.
If you need the prior behavior, feel free to add a layer on top of your call to .read
which does this sort of forced rewriting of the zone--there's example code in the read task: https://github.com/photostructure/exiftool-vendored.js/blob/df569e630791df3655cb13c559e1dd7569b22b1a/src/ReadTask.ts#L292
First thanks again for this useful lib. I realized that we're both writing a tool to sort our photos. Maybe we should compare notes ๐
Describe the bug A few month ago, the timezone on the attached picture was properly recognized as
Australia/Sydney
and passed as such inExifDateTime
(the picture was indeed taken in Sydney)However, restarting dev today with the latest version of exiftool-vendored, the timezone is now reported as
UTC+10
To Reproduce Here is the picture (HEIC) IMG_7477.heic.zip
From XnView "EXIF" view we can see
Date taken 28/07/2020 - 12:18:21 AEDT
(this is correct, taken at lunch time)Expected behavior The timezone should be
Australia/Sydney
Environment (please complete the following information):
Thanks!