Fix timestamp when looking at photos - #3571
Conversation
a492882 to
d1f68f6
Compare
|
Hello there, We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process. Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6 Thank you for contributing to Nextcloud and we hope to hear from you soon! (If you believe you should not receive this message, you can add yourself to the blocklist.) |
4de4d05 to
f2051ca
Compare
DateTime::createFromFormat() can successfully parse dates that produce a Unix timestamp of 0 (e.g. EXIF DateTimeOriginal '1970:01:01 00:00:00' from a camera with a reset clock). The strict !== false check did not catch this, so original_date_time was stored as 0. A value of 0 sorts to the very bottom of the DAV SEARCH results ordered by this field DESC, making those photos unreachable via offset-based pagination. Treat any parsed timestamp <= 0 as a parse failure and fall through to the next method. Fixes: nextcloud#2768 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> Signed-off-by: Corentin No毛l <corentin.noel@collabora.com>
Non-standard S3-compatible storage backends may return 0 for the Last-Modified header, causing getMTime() to return 0. Storing that value as original_date_time would sort the file to the bottom of the DAV SEARCH results ordered DESC, making it unreachable via offset-based pagination. When mtime is 0 we leave the metadata unset (NULL) rather than writing 0. NULL is an acceptable unknown; 0 actively breaks sorting. Fixes: nextcloud#2768 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> Signed-off-by: Corentin No毛l <corentin.noel@collabora.com>
f2051ca to
3b515af
Compare
| $mtime = $node->getMTime(); | ||
| if ($mtime > 0) { | ||
| $metadata->setInt(self::METADATA_KEY, $mtime, true); | ||
| } |
There was a problem hiding this comment.
Let's keep meaningful fallback, else, the file won't even be included in requests filtering by photos-original_date_time.
| $mtime = $node->getMTime(); | |
| if ($mtime > 0) { | |
| $metadata->setInt(self::METADATA_KEY, $mtime, true); | |
| } | |
| $mtime = $node->getMTime(); | |
| if ($mtime > 0) { | |
| $metadata->setInt(self::METADATA_KEY, $mtime, true); | |
| return; | |
| } | |
| $metadata->setInt(self::METADATA_KEY, $node->getUploadTime(), true); |
4 participants
Reject timestamp 0 as it is very unlikely to represent the right time and least to photos being unsorted.
This is especially true for my setup using the S3 from OVH that seem to not return the mtime.
馃 AI (if applicable)
Fixes: #2768