icloud-photos-downloader / icloud_photos_downloader

A command-line tool to download photos from iCloud
MIT License
6.85k stars 554 forks source link

Time Zone not works. #714

Closed bowencool closed 11 months ago

bowencool commented 11 months ago

Overview

This is the info in iCloud:

image

This is the info in icloudpd-downloaded:

image

The logs do not match system time also:

image

Steps to Reproduce

here is my script:

icloud_home=/mnt/xxx/icloudpd
mkdir -p ${icloud_home}
docker run -it --rm --name icloudpd \
    -v ${icloud_home}/Photos:/data \
    -v ${icloud_home}/cookies:/cookies \
    -e TZ=Asia/Shanghai \
    icloudpd/icloudpd:latest \
    icloudpd --directory /data \
    --cookie-directory /cookies \
    --folder-structure {:%Y/%Y-%m-%d} \
    --username xxx \
    --password xxx \
    --size original \
    --domain cn \
    --auto-delete

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

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

boredazfcuk commented 11 months ago

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 commented 11 months ago

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 commented 11 months ago

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):

283088895-370a7fb3-3f6e-4d30-b92f-4ad83f6f5458

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 commented 11 months ago

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

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:

image

MacOS:

image

I'm checking the original information in the Photos app(MacOS):

image

I am accessing the file downloaded by unRAID using Finder via SMB:

image
bowencool commented 11 months ago

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

image
AndreyNikiforov commented 11 months ago

From the data above, it looks to me:

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 commented 11 months ago

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 commented 11 months ago

... 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 commented 11 months ago

... 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 commented 11 months ago

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

bowencool commented 11 months ago

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

I encountered #717 in various ways.