Closed bowencool closed 11 months ago
Looks like the difference in time is related to timezone (8hr for Shanghai). What time zone do you have on iPhone where you took picture, device (Mac?) where you saw iCloud data and device where you run docker image?
icloudpd uses local timezone (in docker in your case) to setup time.
To show correct time in the log files inside my container, I install the tzdata package from the OS repo:
apk add --no-progress --no-cache tzdata
Maybe there is an issue with the pyinstaller tzdata package?
To show correct time in the log files inside my container, I install the tzdata package
In other docker containers I saw ppl mounting /etc/localtime from the host, e.g. -v /etc/localtime:/etc/localtime:ro
. IIUC that approach does not need tzdata in container.
Maybe there is an issue with the pyinstaller tzdata package?
I wonder how can we reproduce the issue reliably?
Maybe it's operating on different levels? In this screenshot, it shows the correct time zone information in the log file (which should be handled by Python's tzdata package):
However, the date
command run immediately after shows a different date. This won't be using pyinstaller's tzdata and will be pulling the system time zone, which is defaulting to CST, at a guess.
@bowencool zooming out a bit: how do you use OS-level attributes of the downloaded files? If your assets have right EXIF data inside, I assume all image manipulation software will use EXIF and don't pay attention to file attributes.
Looks like the difference in time is related to timezone (8hr for Shanghai). What time zone do you have on iPhone where you took picture, device (Mac?) where you saw iCloud data and device where you run docker image?
icloudpd uses local timezone (in docker in your case) to setup time.
My iPhone, Mac, and NAS (unRAID) are all set to Beijing time (UTC +8), and they are all located in China. I'm not sure what the "C" in "CST" stands for, is it "China" or "Central"?
unRAID:
MacOS:
I'm checking the original information in the Photos app(MacOS):
I am accessing the file downloaded by unRAID using Finder via SMB:
I am using MtPhotos to view EXIF data and have noticed conflicts within the data:
{
"ExifToolVersion": 12.4,
"FileName": "IMG_3842.JPG",
"FileModifyDate": "2023:11:10 04:00:37+08:00",
"FileAccessDate": "2023:11:10 04:00:37+08:00",
"FileInodeChangeDate": "2023:11:16 10:56:34+08:00",
"ModifyDate": "2023:11:09 20:00:37",
"DateTimeOriginal": "2023:11:09 20:00:37",
"CreateDate": "2023:11:09 20:00:37",
"GPSDateStamp": "2023:11:09",
"SubSecCreateDate": "2023:11:09 20:00:37.607+08:00",
"SubSecDateTimeOriginal": "2023:11:09 20:00:37.607+08:00",
"SubSecModifyDate": "2023:11:09 20:00:37+08:00",
"GPSDateTime": "2023:11:09 11:58:34Z"
// ...
}
The values for FileAccessDate
and FileModifyDate
are incorrect.
They should be either "2023-11-09 20:00:37+08:00" or "2023-11-09 12:00:37+00:00".
From the data above, it looks to me:
Two approaches from here that I see:
I am leaning toward the former (remove file attributes at all) and would love to hear other opinions.
From the data above, it looks to me:
- image was taken 2023-11-09 20:00:37+08:00 (this is CST); that is recorded as DateTimeOriginal without timezone info
- folder structure was correctly created using 09 day of month
- File attributes (Created & Modified) were set with extra 8hrs adjustment as if TZ was applied twice
Two approaches from here that I see:
- do not set file attributes at all and set correct expectations; rationale: IIUC, most/all image organizing and manipulating software use EXIF/XMP, not file attributes
- figure out why timezone calc was applied to file attributes incorrectly, fix, and, possibly, add extra setup to code/doc
I am leaning toward the former (remove file attributes at all) and would love to hear other opinions.
I recommend the latter.
We will miss this feature of setting file attributes if someone else fixes the TZ issue. This absence may confuse those who are accustomed to using it.
... This absence may confuse those who are accustomed to using it.
I am trying to understand how people are accustomed to using file attributes of image/videos, especially if attributes are incorrect. Since attributes are incorrect (and I suspect for a long time) it is very reasonable to assume that they are not used at all. Are you using/relying of file attributes yourself? How? I do not pay any attention to them at all. BTW I don't rely on dates in folder hierarchy either, but storing all photos in one big folder has other challenges, so I am using hierarchy.
... This absence may confuse those who are accustomed to using it.
I am trying to understand how people are accustomed to using file attributes of image/videos, especially if attributes are incorrect. Since attributes are incorrect (and I suspect for a long time) it is very reasonable to assume that they are not used at all. Are you using/relying of file attributes yourself? How? I do not pay any attention to them at all. BTW I don't rely on dates in folder hierarchy either, but storing all photos in one big folder has other challenges, so I am using hierarchy.
No, I'm not using file attributes.
@bowencool pls check if 1.16.3 works for you and reopen the issue if it does not.
@bowencool pls check if 1.16.3 works for you and reopen the issue if it does not.
I encountered #717 in various ways.
Overview
This is the info in iCloud:
This is the info in icloudpd-downloaded:
The logs do not match system time also:
Steps to Reproduce
here is my script:
Expected Behavior
The downloaded photos should have the exact same information as their info in iCloud.
Actual Behavior
The information of the downloaded photos does not match their information in iCloud.
Context