GNOME Bugzilla – Bug 774492
Modifed and Modified - Time columns do not display standard values
Last modified: 2021-06-18 15:55:47 UTC
Neither the 'Modified', nor the 'Modified - Time' display the date in any sort of standardized way. Values include, but aren't limited to; nothing 'Today' 'Yesterday' <Day of Week> <date> <Month> <date> <Month> <Year> Often mixing values within the same directory. Occasionally it results in nonsensical results. Example: Currently 13:00, there are two files in the directory. One was modified at 12:00 today, the other was modified at 14:20 _yesterday_. Nautilus lists the 'Modified - Time' values as: 12:00 and 14:20. According to Nautilus the second file was modified an hour and 20 minutes in the future. Nautilus should provide some mechanism to set the display in some standardized format, at least as ISO date-time strings yyyy-MM-dd hh:mm:ss
Those "standard ISO formats" are for machines. The UI displays a human readable string for the date. The ISO format is in the properties of the file, right click -> properties in case you need it for some reason, as raw property of the metadata of the file. Regarding the "in future modification" please file a new bug report and we will look into it. Thanks
Those formats are _not_ just for machines as evidenced by this very page: "[reply] [−] Comment 1 Carlos Soriano [nautilus developer] 2016-11-16 12:03:21 UTC" Having the option of viewing all modified dates in the same format makes sorting and searching much easier. Having a wide variety of non-standard date strings makes it more difficult than it needs to be. The user should be allowed to change the format of the date string presented.
(In reply to coleman.rik from comment #2) > Those formats are _not_ just for machines as evidenced by this very page: > > "[reply] [−] Comment 1 Carlos Soriano [nautilus developer] 2016-11-16 > 12:03:21 UTC" Indeed! Something I don't agree with Bugzilla (apart of other millions things) :) > > Having the option of viewing all modified dates in the same format makes > sorting and searching much easier. Having a wide variety of non-standard > date strings makes it more difficult than it needs to be. Hm not sure, in what case makes it easier to quickly understand "Yesterday", "Tuesday" rather than 21-09-2016? The latest you have to think about it. Sorting works fine, since it's using the real ISO date to sort...and searching the same, using the search options. What I'm not sure is what use cases you are finding that you feel is better to use these ISO formats, and why right click-> properties is not enough for you. Afaics sorting and searching is not a problem. > > The user should be allowed to change the format of the date string presented. Hm not really, we would use the local format. However we present it in a more friendly way when it's a date close to the current day.
While you may disagree with the Bugzilla devs, it was just presented to illustrate that large numbers of developers (and of course users) don't happen to agree with your statement that ISO date formats are only for computers. The difficulty is the mental gymnastics needed to internally convert from one to the other. As an example: You are looking for files between '2016-11-19 23:30' and '2016-11-20 23:30' because you suspect that they are invalid in some way. While there are several hundred files in that folder, there may be none, one, or a few files that fit that criteria. In the proposed scheme: Open the folder in details view, sort on modified, scroll down to '2016-11-19' browse the timestamps for files in the required window. Done. In the current nautilus scheme: Open the folder in details view, sort on modified, figure out what day 'today' is. Do the mental calculation to figure out what files fit the criteria, because it _changes_ based on _when_ you look at the folder. If 'today' is the 20th, you are looking for 'today' and perhaps 'yesterday', or maybe 'yesterday' and 'Sat.', or 'Sat.' and 'Sun.', or '19-Nov.' and 'Sun.'. Sure the current datetime string looks 'pretty', especially for _casual_ users, but it's terribly counter productive otherwise. I hope that helps,
(In reply to coleman.rik from comment #4) > While you may disagree with the Bugzilla devs, it was just presented to > illustrate that large numbers of developers (and of course users) don't > happen to agree with your statement that ISO date formats are only for > computers. Oh sure, I was not expecting everyone agreeing... :) > > The difficulty is the mental gymnastics needed to internally convert from > one to the other. As an example: > > You are looking for files between '2016-11-19 23:30' and '2016-11-20 23:30' > because you suspect that they are invalid in some way. While there are > several hundred files in that folder, there may be none, one, or a few files > that fit that criteria. > > In the proposed scheme: > Open the folder in details view, sort on modified, scroll down to > '2016-11-19' browse the timestamps for files in the required window. > > Done. This confuses me. So you will know the number of the day of the month you modified a file, but you won't know it was on "Tuesday"? That looks very unlikely, I expect people to remember more if it was "last Tuesday" rather than "the 21-10-2016 day". > > In the current nautilus scheme: > Open the folder in details view, sort on modified, figure out what day > 'today' is. Do the mental calculation to figure out what files fit the > criteria, because it _changes_ based on _when_ you look at the folder. If > 'today' is the 20th, you are looking for 'today' and perhaps 'yesterday', or > maybe 'yesterday' and 'Sat.', or 'Sat.' and 'Sun.', or '19-Nov.' and 'Sun.'. > > Sure the current datetime string looks 'pretty', especially for _casual_ > users, but it's terribly counter productive otherwise. Well, if you think what I do is casual, yes. But really, I agree on having "Tuesday" etc. because it was also better for me. Not sure what other common cases would be terribly counter productive. > > I hope that helps, Thanks for the time on explaining a case, really. However, either I didn't understood the case, or it doesn't make sense to me to remember the number of the day but not the week day. Also, I think it's uncommon to search for ranges of dates in files scrolling down. For that we have the search popover, where you can search for file types, date ranges, etc. Although it could be more inconvenient than scrolling down when you have not many files in the folder, seems also an uncommon case. Do you have another use case in mind?
Personally I almost always know the number of the date I am interested in, while I almost _never_ need to know the day of the week that number corresponds to (and nautilus currently forces me to reference a calendar). My most common use case involves looking/editing/creating files that were generated with a timestamp: Log files (ex: missing a backup from 2016-11-10, what happened?) sFTP uploads (ex: client sent a batch on 2016-11-02, reprocess it) Git commits (ex: when was that file in commit 60916e331b55 last edited) I could go on, but I think you get the idea. Timestamp == 'good', Pretty Date == 'bad'. Apparently you are not disturbed by the fact that what you are searching for mutates depending on _when_ you run the search. Personally I find it more productive to be able to always look for the same string regardless of when I happen to be looking. Most of the other file managers that I have seen have at least a setting to switch the detailed display to a timestamp for the date modified column; Dolphin, Thunar, even FileExplorer on Windows. Is there any reason why one couldn't be added to Nautilus as well?
(In reply to coleman.rik from comment #6) > Personally I almost always know the number of the date I am interested in, > while I almost _never_ need to know the day of the week that number > corresponds to (and nautilus currently forces me to reference a calendar). > My most common use case involves looking/editing/creating files that were > generated with a timestamp: > > Log files (ex: missing a backup from 2016-11-10, what happened?) > sFTP uploads (ex: client sent a batch on 2016-11-02, reprocess it) > Git commits (ex: when was that file in commit 60916e331b55 last edited) > Hm fair enough. Worth asking designers at this point then... > I could go on, but I think you get the idea. Timestamp == 'good', Pretty > Date == 'bad'. Apparently you are not disturbed by the fact that what you > are searching for mutates depending on _when_ you run the search. > Personally I find it more productive to be able to always look for the same > string regardless of when I happen to be looking. > > Most of the other file managers that I have seen have at least a setting to > switch the detailed display to a timestamp for the date modified column; > Dolphin, Thunar, even FileExplorer on Windows. Is there any reason why one > couldn't be added to Nautilus as well? The same reasons for adding anything new to nautilus, needs to be discused, understand the reasons and use cases and ponder the worth of it versus the complexity and maintenability added.
*** Bug 729078 has been marked as a duplicate of this bug. ***
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of Files (nautilus), then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/nautilus/-/issues/ Thank you for your understanding and your help.