GNOME Bugzilla – Bug 756402
Modification date column is calculated based on a time span instead of a date difference
Last modified: 2017-02-26 10:21:37 UTC
The modification date column is calculated based on a time span instead of a date difference. This means that: * a file that was changed yesterday can have a modification date shown in hours and minutes * a file that was changed a week ago has a modification date shown as a weekday. Only the date part of the modification time should be used in this calculation.
To expand on this, I don't have an issue with files modified in the last 24 hours (regardless of which day they fall into) only displaying their modification time, but a regression seems to have appeared in the 3.18 releases that now bases this calculation on a 48 hour window. I'm not running a 3.16 or older version to compare against at the moment, but on Fedora 23 running Nautilus 3.18.3, I see confusing lists like this: File X 9pm File Y 2pm File Z 10pm Where File Z was modified *TWO* days ago, but is still being displayed with just the modification time, which is rather confusing. (Like I said, I'm pretty sure this is a regression. I just don't have the capacity to confirm that at the moment. That is, I can't possibly imagine someone added that change as a feature!)
This is still an issue with 3.20.1.
Not sure how related this is, but the only issue I see is files, modified two days ago, are reported to have been modified yesterday. This is because the calculation involves today’s /date/ and the file’s mtime, but the NautilusFile vfunc returning it is named nautilus_file_get_date(), making the implementations technically incorrect and causing confusion. A possible solution I see is taking only the date portion of the constructed GDateTime (by using an intermediary variable). Will attach a patch soon.
Created attachment 330348 [details] Example of ambiguous times shown for files modified on different days
Created attachment 330350 [details] [review] file: fix date string day difference calculation nautilus_file_get_date_as_string() uses today's date and the GDateTime constructed from the return value of nautilus_file_get_date(), which also includes the time of day, thus making the calculation of the day difference incorrect. To illustrate, files, modified two days ago can appear to have been modified yesterday. This commit fixes that by calculating the day difference of the dates with the time value of 00:00:00.
(In reply to Neil Herald from comment #4) > Created attachment 330348 [details] > Example of ambiguous times shown for files modified on different days Thanks! This is exactly what I was after.
You beat me to it Ernestas, I was just about to jump on this one :) What seems to be happening: A. If the file is modified today or yesterday => show only the time B. If the file was modified 2 days ago (note: not yesterday!) => show "Yesterday" C. If the file was modified earlier than that, show some description A and B are wrong IMO. I've just applied your patch to try it out: it fixes both of these (for the example in the screenshot anyway), time presentation looks a lot better now :)
(In reply to Neil Herald from comment #7) > What seems to be happening: > A. If the file is modified today or yesterday => show only the time > B. If the file was modified 2 days ago (note: not yesterday!) => show > "Yesterday" > C. If the file was modified earlier than that, show some description > > A and B are wrong IMO. I've just applied your patch to try it out: it fixes > both of these (for the example in the screenshot anyway), time presentation > looks a lot better now :) Yes, that's exactly what I was getting at, A and B are wrong (and so confusing to deal with when quickly trying to check a bunch of files). Thanks to both of you for looking into this.
Review of attachment 330350 [details] [review]: good catch, thanks a lot!
Attachment 330350 [details] pushed as 072e067 - file: fix date string day difference calculation
Could this please be pulled into a 3.20 point release (if that's not already happening)?
(In reply to David H. Gutteridge from comment #11) > Could this please be pulled into a 3.20 point release (if that's not already > happening)? It’s been done. Thanks for the reminder.
Confirming 3.20.2 fixes the issue for me, thanks!
(In reply to David H. Gutteridge from comment #13) > Confirming 3.20.2 fixes the issue for me, thanks! Awesome! Thanks for getting back to us!
*** Bug 763341 has been marked as a duplicate of this bug. ***
*** Bug 774964 has been marked as a duplicate of this bug. ***