Time Zone not works. about icloud_photos_downloader

[AndreyNikiforov]

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.

[boredazfcuk]

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?

[AndreyNikiforov]

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?

[boredazfcuk]

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.

[AndreyNikiforov]

@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.

[bowencool]

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:

[bowencool]

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".

[AndreyNikiforov]

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:

1. 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
2. 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.

[bowencool]

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:

1. 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
2. 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.

[AndreyNikiforov]

... 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.

[bowencool]

... 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.

[AndreyNikiforov]

@bowencool pls check if 1.16.3 works for you and reopen the issue if it does not.

[bowencool]

@bowencool pls check if 1.16.3 works for you and reopen the issue if it does not.

I encountered #717 in various ways.