Conversation
WalkthroughThe call to SearchMemoriesAsync now uses DateTime.Today.ToUniversalTime() instead of DateTime.Now, changing the date boundary used when retrieving memories. No other logic or control flow was modified. Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
ImmichFrame.Core/Logic/Pool/MemoryAssetsPool.cs (1)
43-43: Cache expiration uses local time while API now uses UTC.The cache expires at local midnight (
DateTimeOffset.Now.Date.AddDays(1)), but the API call now uses UTC dates. This mismatch could cause cache invalidation at the wrong time:
- Cache expires at 00:00 local time
- API boundary is at 00:00 UTC
- For GMT+9 users, the cache expires 9 hours after the UTC day boundary
Consider aligning both to the same timezone—either both UTC or both local—to ensure cache invalidation happens when the data actually changes.
If the API uses UTC dates, update the cache expiration accordingly:
- AbsoluteExpiration = DateTimeOffset.Now.Date.AddDays(1) + AbsoluteExpiration = DateTimeOffset.UtcNow.Date.AddDays(1)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
ImmichFrame.Core/Logic/Pool/MemoryAssetsPool.cs(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Analyze (csharp)
There was a problem hiding this comment.
🧩 Analysis chain
Verify timezone conversion logic—may worsen the issue for positive UTC offsets.
Using DateTime.Today.ToUniversalTime() converts local midnight to UTC, which shifts the date backward for users ahead of UTC. For example, if a user in GMT+9 runs this code at 08:00 on October 13:
DateTime.Today= October 13, 00:00:00 (local)DateTime.Today.ToUniversalTime()= October 12, 15:00:00 (UTC)
This could cause the API to return memories from October 12 instead of October 13, potentially exacerbating issue #478 rather than fixing it.
Consider these alternatives based on what SearchMemoriesAsync expects:
- If the API expects UTC dates: Use
DateTime.UtcNow.Date(today's date in UTC) - If the API expects local dates: Use
DateTime.Today(without conversion) - If timezone context is required: Use
DateTimeOffsetwith the appropriate offset
Run the following script to check the API contract and understand what SearchMemoriesAsync expects:
Additionally, please search the web for Immich API documentation on memory search endpoints:
🏁 Script executed:
#!/bin/bash
# Description: Find the SearchMemoriesAsync definition to verify expected parameter type
ast-grep --pattern 'SearchMemoriesAsync($$$)'Length of output: 0
🌐 Web query:
What date/time format does the Immich API SearchMemories endpoint expect? Does it expect UTC or local time?
💡 Result:
Short answer: Use an ISO 8601 / RFC3339 date-time string including timezone. Immich stores/returns UTC timestamps (e.g. fileCreatedAt is the UTC timestamp) and also exposes a timezone-agnostic localDateTime for local grouping. If you want an absolute moment, send/parse timestamps with timezone (or Z for UTC), e.g. 2023-09-01T12:34:56Z. [1][2]
Sources:
- Immich search-memories API docs (date-time fields; fileCreatedAt = UTC). [1]
- Immich searchMetadata / behavior notes (localDateTime vs timezone; metadata extraction uses timezone info or falls back). [2]
Use UTC today’s date for SearchMemoriesAsync
DateTime.Today.ToUniversalTime() shifts local midnight into the previous day in UTC for positive offsets. Use DateTime.UtcNow.Date to send today’s date at 00:00 UTC (e.g. 2025-10-13T00:00:00Z), matching the API’s ISO 8601 UTC requirement.
🤖 Prompt for AI Agents
In ImmichFrame.Core/Logic/Pool/MemoryAssetsPool.cs around line 12, the call uses
DateTime.Today.ToUniversalTime(), which can roll local midnight into the
previous UTC day; change it to use today's date at midnight UTC by using
DateTime.UtcNow.Date when calling SearchMemoriesAsync so the API receives 00:00
UTC for the current day.
| protected override async Task<IEnumerable<AssetResponseDto>> LoadAssets(CancellationToken ct = default) | ||
| { | ||
| var memories = await immichApi.SearchMemoriesAsync(DateTime.Now, null, null, null, ct); | ||
| var memories = await immichApi.SearchMemoriesAsync(DateTime.Today.ToUniversalTime(), null, null, null, ct); |
There was a problem hiding this comment.
There is a UtcNow you could use, but suggests that too :P
| var memories = await immichApi.SearchMemoriesAsync(DateTime.Today.ToUniversalTime(), null, null, null, ct); | |
| var memories = await immichApi.SearchMemoriesAsync(DateTime.UtcNow.Date, null, null, null, ct); |
There was a problem hiding this comment.
It's very confusing. This is what GPT says:
| Method | Sent UTC | Local equivalent | Result |
|---|---|---|---|
DateTime.Today |
2025-10-13 00:00:00 (unspecified) | 2025-10-13 00:00 local | Local midnight, may be misinterpreted as UTC |
DateTime.Today.ToUniversalTime() |
2025-10-13 04:00:00 UTC | 2025-10-13 00:00 local | Correct: midnight local day in UTC |
DateTime.UtcNow.Date |
2025-10-13 00:00:00 UTC | 2025-10-12 20:00 local | Incorrect: local “day” is still 12th → shows yesterday |
2 participants
Closes #478
@JW-CH , do you think this is the issue for users seeing wrong days memories?
Summary by CodeRabbit