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

utc to local timezone handling wrong #1356

Closed
LunarLanding opened this issue Dec 28, 2023 · 4 comments · Fixed by #1357
Closed

utc to local timezone handling wrong #1356

LunarLanding opened this issue Dec 28, 2023 · 4 comments · Fixed by #1357
Labels
bug Something isn't working

Comments

@LunarLanding
Copy link
Contributor

LunarLanding commented Dec 28, 2023

Describe the bug
When importing from Google Takeout while using the sidecar information, the local timezone is applied cumulatively twice, resulting in wrong timestamps being set in Photos.

To Reproduce
Steps to reproduce the behavior:

  1. What' the full command line you used with osxphotos?
    osxphotos import ./Takeout/p1 --relative-to . --walk --album "{filepath.parent}" --skip-dups --dup-albums --sidecar --verbose --keyword "{person}" --report takeout_import.csv --resume --append --split-folder "/"

No errors on the command line.

Expected behavior
UTC to local timezone transformation applied once on the sidecar timestamp.

Print-outs

Reading :

if timestamp:
try:
date = datetime.datetime.fromtimestamp(int(timestamp))
except ValueError:
date = None
if date:
# Takeout JSON stores date as timestamp in UTC
# regardless of timezone of photo
# convert to naive datetime in local timezone
# as that's what Photos uses
date = datetime_remove_tz(
datetime_utc_to_local(datetime_naive_to_utc(date))
)

This is what happens now:

dt=datetime.datetime.fromtimestamp(1599158718)
print(dt,dt.tzinfo)
if dt.tzinfo is not None and dt.tzinfo.utcoffset(dt) is not None:
    raise ValueError
print(dt,dt.tzinfo)
dt=dt.replace(tzinfo=datetime.timezone.utc)
print(dt,dt.tzinfo)
dt=dt.astimezone(tz=None)
print(dt,dt.tzinfo)
2020-09-03 19:45:18 None
2020-09-03 19:45:18 None
2020-09-03 19:45:18+00:00 UTC
2020-09-03 20:45:18+01:00 WEST

This is what should be happening:

dt=datetime.datetime.fromtimestamp(1599158718,datetime.timezone.utc)
print(dt,dt.tzinfo)
dt=dt.astimezone(tz=None)
print(dt,dt.tzinfo)
2020-09-03 18:45:18+00:00 UTC
2020-09-03 19:45:18+01:00 WEST

Desktop (please complete the following information):

  • OS: Sonoma 14.2.1
  • osxphotos version : 0.67.0

Additional context
I might be missing some other case where setting it to UTC would fail but I'll link a pull request for now.

@RhetTbull
Copy link
Owner

These two times are the same.

When it is 2020-09-03 20:45:18+01:00 WEST

The time in UTC would be 2020-09-03 19:45:18+00:00 UTC

As UTC is one hour earlier.

What am I missing?

@LunarLanding
Copy link
Contributor Author

datetime_remove_tz will then by doing .replace(tzinfo=None) keep only the left-side of the information, thus Photos gets in one case the wrong one 2020-09-03 20:45:18, and in another the correct one 2020-09-03 19:45:18.

The input to datetime_utc_to_local should be independent of the local timezone, but it is not.

@RhetTbull
Copy link
Owner

Google converts local timezone to UTC in the Takeout sidecar. This local timezone of where the photo was taken is lost. If imported into Photos without conversion Photos will assume the timezone is local timezone. But the time in UTC is not correct for local timezone (unless local is UTC), thus the conversion. I've tested this on a test case for which I know the correct local time and it appears to be working. Entirely possible I've messed up something but I don't understand the situation at the moment. The desired outcome is that the UTC time is translated to the equivalent time in the local timezone. I'm traveling and don't have my Mac with me so can't test at the moment.

@RhetTbull
Copy link
Owner

Ok, I think I see the issue. The initial conversion from timestamp converts a naive time into naive timestamp in local timezone. This may be occurring elsewhere (Eg parse date) so need to ensure that code path is also correct.

@RhetTbull RhetTbull added the bug Something isn't working label Dec 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants