Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Time Zone not works. #714

Closed
bowencool opened this issue Nov 15, 2023 · 13 comments
Closed

Time Zone not works. #714

bowencool opened this issue Nov 15, 2023 · 13 comments
Labels

Comments

@bowencool
Copy link

bowencool commented Nov 15, 2023

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

@bowencool bowencool added the bug label Nov 15, 2023
@AndreyNikiforov
Copy link
Collaborator

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
Copy link
Contributor

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
Copy link
Collaborator

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
Copy link
Contributor

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
Copy link
Collaborator

@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
Copy link
Author

bowencool commented Nov 16, 2023

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
Copy link
Author

bowencool commented Nov 16, 2023

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
Copy link
Collaborator

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
Copy link
Author

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
Copy link
Collaborator

... 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
Copy link
Author

... 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 added a commit to AndreyNikiforov/icloud_photos_downloader that referenced this issue Dec 2, 2023
@AndreyNikiforov
Copy link
Collaborator

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

@bowencool
Copy link
Author

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

I encountered #717 in various ways.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants