Closed mlucianoeze closed 6 days ago
Your system doesn't provide default timezone understandable for immich-go. It happens sometime with some NAS, or with Windows (not always š¤ )
The -time-zone=time_zone_name
just informs the program with your time zone. It will be the default time zone for photos not having the timezone indicated.
You can start importing you takeout and break it quickly to check the result. You can relaunch the command later, the work will resume.
Oh, I see, good to know! Is it worth it to implement a more clear message like 'you need to specify a timezone' on these cases with a previous check? I could help with that if you need. I'm asking beforehand so you can decide what's best, maybe a warning in the readme file would be enough, or even this issue itself may help somebody else to solve this problem :)
The difficulty is to understand why this happens. The system get the local TZ when it starts. If it fails here, a nice message is displayed.
I have tested on a regular linux and windows without finding an issue. Could you tell more about your system?
I just had the same issue (hey neighbour! š¦š· š§ )
cat /etc/timezone
America/Argentina/Buenos_Aires
Looks reasonable. Is it possible that the go utility being used doesn't support all timezones?
I think it is worth at least suggesting in the readme to use the -time-zone
argument (in this case, -time-zone=America/Argentina/Buenos_Aires
).
The exact error I was getting (v0.16) was a little bit different in my case. Pasting it here to help people searching for it
./immich-go -no-ui -server=http://localhost:2283 -key=<mykey> upload -create-albums -google-photos take
out-xxx-001.zip
immich-go 0.16.0, commit 7579f2577f5f24c1e6d3b266989112777332e868, built at 2024-06-02T09:25:25Z
. _ _ _ _ . _|_ _ _
|| | || | ||(_| | ā (_|(_)
v 0.16.0 _)
panic: time: missing Location in call to Time.In
goroutine 16 [running]:
time.Time.In(...)
time/time.go:1167
...
It's basically the same error.
Could you show what the command timedatectl
outputs?
Dual booter here, I had not realized that. It could be related, since I had to configure the clock to avoid the windows/linux clock conflicts
āÆ timedatectl
Local time: Sat 2024-06-08 12:25:04 -03
Universal time: Sat 2024-06-08 15:25:04 UTC
RTC time: Sat 2024-06-08 12:25:04
Time zone: America/Argentina/Buenos_Aires (-03, -0300)
System clock synchronized: yes
NTP service: active
RTC in local TZ: yes
Warning: The system is configured to read the RTC time in the local time zone.
This mode cannot be fully supported. It will create various problems
with time zone changes and daylight saving time adjustments. The RTC
time is never updated, it relies on external facilities to maintain it.
If at all possible, use RTC in UTC by calling
'timedatectl set-local-rtc 0'.
Thanks. Nothing bad.
What's the value of the TZ
environnement variable?
It looks like I have no TZ
variable set in my shell (printenv | grep -i tz
yields nothing relevant).
I haven't set it in my Immich .env
file since I am using the default file downloaded by following the docker compose setup guide. I am reading its documentation and it looks like it should be set as a fallback for exif, but is not required.
Is it possible that is what is causing the issue?
No, it crashes when trying to infer the date of capture using the file name.
Ex: 20111209_110308_6D4DBECF.jpg
should give 2011/12/09 at 11:03:03 Local Time...
The localtime determination fails on your system.
Could you show what the command ls -al /etc/localtime
returns?
Of course
āÆ ls -al /etc/localtime
lrwxrwxrwx 1 root root 50 Mar 3 22:03 /etc/localtime -> /usr/share/zoneinfo/America/Argentina/Buenos_Aires
Note that my OS is Pop!_OS 22.04 LTS
I see. The problem comes from the library lām using to determine the timezone.
Basically, the library takes the file name of the /etc/localtime target, and split it in parts: /usr/share/zoneinfo/America/Argentina/Buenos_Aires gives
and it keep 2 and 3 instead of 1, 2 and 3.
I'll fix the library ASAP. Thanks for your help
Same issue here! America/Argentina/Cordoba. Que onda pibes y pibas? What a funny error
Not funny...
Use the time-zone=time_zone_name
parameter to provide your time zone.
This is corrected in the release to come.
Not funny...
@simulot Look at it from the bright side, how many times does a bug in a software application unite random Argentinians on the internet? :smile:
Not funny because there is always something you haven't yet tested š
The latest release fixes this
Hello there! I'm trying to import a pretty big bunch of Google takeout zip files, and the first thing I stumbled upon is that the program crashes when I try to import them with this command:
This is the output:
Judging by the error message
missing Location in call to Time.In
, it looks like it was expecting a timezone, so I tried the same command but with a tzdata timezone, and it looks like it's working now:I'm not sure if this solution is going to work yet, as this takeout is really big and I've been waiting for quite some time now, but at least it hasn't crashed instantly like it did just before.
Also, I've seen in the code that this timezone thing is per asset, right in line 174 (where it crashes originally): https://github.com/simulot/immich-go/blob/febf80e2acb58afd8a8abd76731eedcb0ab8ff80/browser/gp/googlephotos.go#L171-L182 Does this affect photos taken in different timezones? I don't know exactly how Google saves dates in an asset JSON file, but I think this question is worth asking.
If this fix ends up working, maybe you should consider making the parameter
-time-zone
mandatory, at least on these cases where it's needed. Let me know if you need any help with that :)