That said, maybe there are situations where it is confusing. In that case, we should fix those situations, which might just be a bug. Can you provide an example where there is confusion?
What exactly is the issue here? It’s pretty clear the first one is from today at 11:10, the second from 17 days ago, and the third is from 6 months ago.
The issue is that I can read this faster:
2022-06-11 11:10
2022-05-28 09:44
2021-12-01 22:29
The issue is that I want this format:
YYYY-MM-DD HH:MM
Because I can more readily read a format that goes from largest unit to smallest unit. The three different formats go from Hour to Minute, then Day - Month - Hour - Minute, then Day - Month - Year - Hour - Minute. Each successive format inserts larger units in between the smaller units on the ends and obfuscates the date/time from efficient parsing.
2 Likes
I think faster reading depends on the situation.
The format you want can also be slow to read, because all dates look the same, so it’s hard to tell at a glance which ones are the most recent.
The current format makes it very fast to tell which dates are more recent, even before reading them, because longer dates are older, shorter dates are closer to today!
Faster reading may depend on the situation. But in my situation, I find it faster to read a list of like formats.
Like iOS, Windows, and others, I would like the ability to use a date format that I specify. If the Locale says that the short date/time format is YYYY-MM-DD HH:MM, I want to see that in my file browser. Just like I do in Windows and other OS’.
I understand that you think what it’s doing now is optimal But as the user, I am telling you it’s not optimal for me. And, based on the fact that this has been discussed for three years in the issue tracking system, i’m not alone, and it clearly isn’t going away. But the developers are still spending most of their time telling users that they’re doing it wrong, instead of listening.
3 Likes
I am one of the developers and I’ve been here listening to you.
(Protip: antagonizing someone online is not a good strategy if you wish to convince them to do what you want. 
)
And I keep asking questions because I want to listen more.
Despite my efforts to listen, I have yet to hear anyone state exactly what the underlying problem here is in a direct and objective way. Until now, all I’ve heard are opinionated preferences.
Yet, I’ll keep listening, doing my best not to miss an actual problem definition.
If you figure it out, please don’t hesitate to come back and share it with the community! 
1 Like
So how is this not an opinionated preference? What objective data have you to show that displaying dates in the manner Nautilus does improves the user experience?
Problem: Dates displayed in Nautilus do not follow the Locale settings for format.
Problem: Dates displayed in Nautilus cannot be reformatted to meet user expectations.
Problem: Dates displayed in Nautilus cannot be formatted to follow ISO 8601.
I feel there has to be some kind of fundamental misunderstanding (on my part) of how to explain this so you’ll understand. Asking “but why do you want it to do that?” isn’t helpful. You might as well ask “why do you want to follow ISO 8601?”
I’m really, really, not trying to antagonize you or any developer. What you’re seeing is a user who’s at the end of their rope, and ready to ditch Nautilus entirely, because it won’t do something fundamental that every. other. OS. does properly. I don’t know what problem definition you need that would make the problem clearer, but I feel that the desired goal and the reasons have been hashed out at least three or four times over the last three years in the issue logs, with the same result. I thought i’d take another stab at it, on behalf of those who have gone before.
1 Like
So how is this not an opinionated preference?
There is nothing wrong with having opinionated preferences. We just won’t add options because of personal preferences.
What objective data have you to show that displaying dates in the manner Nautilus does improves the user experience?
Warning: that question works both ways.
But if you insist, Google Drive displays the time in a similar way to our Files app. It doesn’t have an option to set the date format. And it has got over 1 billion active users. How can I change the date format in Google Drive? It shows "Modified May 13, 2019 by me"; I want "20 - Google Drive Community
Problem: Dates displayed in Nautilus do not follow the Locale settings for format.
Then the solution is to follow Locale. Not adding more options.
Problem: Dates displayed in Nautilus cannot be reformatted to meet user expectations.
Problem: Dates displayed in Nautilus cannot be formatted to follow ISO 8601.
You’ve stated 2 facts. Maybe these 2 facts are causing problems. In that case, I’d like to know what problems these 2 facts cause.
The point was that the current “option” is a result of a personal preference.
Yes, and I wasn’t asking for your data. I was pointing out that the decision can be made without data, as was done when the program was written.
And Windows and iOS both can be set up the way I am asking for. I don’t know the number of active users but i’d hazard a guess that it’s comparable to Google.
Ah! Now we’re getting somewhere. So how do we go about requesting that Nautilus look to the Locale settings for date format?
Hum? There is no current option!?
I’m not sure if you are trolling here, or just misunderstood what an option is.
Assuming the later, let me clarify: an option is a control in the user interface which allows the user to change something in the user interface. E.g.: “Sort folders before files” is an option the Files app has.
Yes, and I wasn’t asking for your data. I was pointing out that the decision can be made without data, as was done when the program was written.
Ah, okay, fair. Indeed, it’s unrealistic to get hard data for every little decision.
But it doesn’t mean we have to make mindless decisions. There is a lot of soft data sources we can use to make informed decisions:
- User feedback:
- feedback that people give us directly, like the current thread;
- feedback we get indirectly, by looking at what people are saying on social networks and comment sections;
- bug reports (and the number of
a report gets);
- Contributors feedback (contributors are users too, but they have got deeper insights into the issues and their wider implications)
- Designer expertise (our most trustworthy and qualified source, though I can challenge their decisions if the other sources point in the opposite direction)
- Maintainer expertise
- Technical feasibility (and someone finding time to implement it)
- Maintenance burden (even if someone implements it, it doesn’t mean we can afford to maintain it for years to come).
Although we do listen to user feedback a lot (even seeking more feedback on the internet), we’ve got other sources to inform our decisions. Listening to users doesn’t mean doing everything the most vocal users ask.
First you should confirm that what you see is actually not following the locale settings.
For instance, it’s possible to display the time without the date while following the Locale (e.g. HH:MM). It’s also possible to display the date without the time all the while following the Locale.
You can confirm your current locale data using the following command:
locale -k LC_TIME
Here is mine, for reference:
[antonio@computer ~]$ locale -k LC_TIME
abday="dom;seg;ter;qua;qui;sex;sáb"
day="domingo;segunda;terça;quarta;quinta;sexta;sábado"
abmon="jan;fev;mar;abr;mai;jun;jul;ago;set;out;nov;dez"
mon="janeiro;fevereiro;março;abril;maio;junho;julho;agosto;setembro;outubro;novembro;dezembro"
am_pm=";"
d_t_fmt="%a %d %b %Y %T"
d_fmt="%d/%m/%Y"
t_fmt="%T"
t_fmt_ampm=""
era=
era_year=""
era_d_fmt=""
alt_digits=
era_d_t_fmt=""
era_t_fmt=""
time-era-num-entries=0
time-era-entries="d"
week-ndays=7
week-1stday=19971130
week-1stweek=4
first_weekday=2
first_workday=2
cal_direction=1
timezone=""
date_fmt="%a %d %b %Y %T %Z"
time-codeset="UTF-8"
alt_mon="janeiro;fevereiro;março;abril;maio;junho;julho;agosto;setembro;outubro;novembro;dezembro"
ab_alt_mon="jan;fev;mar;abr;mai;jun;jul;ago;set;out;nov;dez"
As you can see here, the locale defines how to display only time, only date, both date and time, both date and time plus timezone, etc… the locale defines all these formats, it doesn’t mandate a single format.
That said, it’s possible Files is not following these formats. In that case, it’s a bug and it should be fixed.
1 Like
Sorry, not trolling at all, possibly a poor choice of terminology. By “the current option” I meant “the option chosen when the program was written.” When the program was written and someone had to choose between various options for displaying dates, the one programmed in was the “option” that was chosen.
Here’s mine:
rb4@Spectre:~$ locale -k LC_TIME
abday="Sun;Mon;Tue;Wed;Thu;Fri;Sat"
day="Sunday;Monday;Tuesday;Wednesday;Thursday;Friday;Saturday"
abmon="Jan;Feb;Mar;Apr;May;Jun;Jul;Aug;Sep;Oct;Nov;Dec"
mon="January;February;March;April;May;June;July;August;September;October;November;December"
am_pm="AM;PM"
d_t_fmt="%a %d %b %Y %r"
d_fmt="%Y-%m-%d"
t_fmt="%r"
t_fmt_ampm="%I:%M:%S %p"
era=
era_year=""
era_d_fmt=""
alt_digits=
era_d_t_fmt=""
era_t_fmt=""
time-era-num-entries=0
time-era-entries="S"
week-ndays=7
week-1stday=19971130
week-1stweek=1
first_weekday=1
first_workday=2
cal_direction=1
timezone=""
date_fmt="%a %d %b %Y %r %Z"
time-codeset="UTF-8"
alt_mon="January;February;March;April;May;June;July;August;September;October;November;December"
ab_alt_mon="Jan;Feb;Mar;Apr;May;Jun;Jul;Aug;Sep;Oct;Nov;Dec"
This is the locale-provided date (without time) format.
These codes convert to something like:
- 2022-06-18
Is this how Files displays date without time in your system? If not, that’s a bug that needs to be reported.
This is the time with seconds without date format provided by the locale. Unfortunately the locale doesn’t define the format for time without seconds.
For the list view in Files, displaying seconds is undesirable. There is no locale-defined format which fulfills our use case. Therefore, in this case it’s not a Files bug. The locales are just not comprehensive enough.
Column on the left is “Modified” and on the right is “Modified - Time”. Happy to enter a bug for this.
1 Like
I agree, seconds aren’t generally desirable. I have had situations where I needed to know the seconds, but rarely. Still, if there was a Locale that defined the time format, and Files followed it, then people could have what they wanted.
Please do, I can fix that
I just realized that this isn’t even true. Anything done “yesterday” will bump the size out by the addition of “yesterday”. So Today’s will be the shortest (time only) then huge on things done yesterday, then small again for things the day before (dayname/time), then on to (day/month/time).
1 Like
It’s just one word, so it’s shorter.
I would have written “narrower” if I meant the width in pixels.