You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
📅 Adjust date display in modified column to be more useful #29807
Please use the 👍 reaction to show that you are interested into the same feature.
Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
Subscribe to receive notifications on status change and new comments.
Is your feature request related to a problem? Please describe.
Searching a file with a specific date in a long ist of files is difficult, because it's always displayed as "x months ago". The real date is in the "title", but this doesn't help much.
Describe the solution you'd like
Add an option to the menu in the lower left corner to switch between a "x days ago" and a date display according to users selected locale.
There should be an option to show time stamps via locale settings, rather than relative date. I think many people would prefer a plain date format.
Describe alternatives you've considered
Using the client or WebDAV and an other file manager on the client, but this is not always a possibility.
Last issue I could find #10258 appears to be closed without discussion.
Reacted by XueSheng-GIT, dugite-code, thmmue, axel, Eric Loyd, brzeziniol, Peter Stamfest, chrizzlibaer, terrancewong, breemts and 53 more
The problem with the relative dates is when they're older than a week. If today is may 13, telling me file is 8 months old doesn't tell me its date. Rather I need to think what was 8 months ago. Having a proper date stamp identifies the date immediately.
Reacted by Kamil Cukrowski, HKx2007, aentrepreneur, jimihend2 and sk8connection
Actual date option would be fantastic. To avoid arguments (US vs International) maybe ISO date format?
YYYY-MM-DD hh:mm:ss
I realize relative is friendly and maybe easier for some people but if you have a lot of files and need to know exactly when, relative is cumbersome/inaccurate to use. The fuzzyness of the relative date format for technical/scientific people is very triggering too. Generally people know today's date and if they need a file from 2 minutes ago or 2 days 3 hours 15 minutes ago, or the file they saved last week Thursday just after lunch time, they can figure that out easier with a proper time stamp then with the fuzzy relative style.
Reacted by Kamil Cukrowski, Giovanni Panozzo, Ayla Novariu Dragon, Moritz Duge and sk8connection
We also would love to have this option. It could be a user option and the default could remain relative date format. This way the simplicity (argument #10258 (comment)) is kept.
I imagine two other options: absolute (according to locale) and custom (for choosing ISO format or different locale)
Reacted by Kamil Cukrowski, jimihend2 and sk8connection
It would still be nice to have an actual time/date displayed, especially when trying to ascertain date/time of multiple files. Such option can be user selectable - use old view or new view with full date/time stamps.
Reacted by Kamil Cukrowski, Tom Mittelstädt, Audun Myhra Bergwitz and sk8connection
Problem I have with the fuzzy time is if multiple files are produced per day or per hour, you end up forever hovering over the column and scrolling to find the right file. I actually have changed some files to include the Date/Time in the name so that they are easier to find. If I try to find a file which I created this time last year and I create multiple files per day its a challenging exercise sometimes I resort to logging in to the server and finding the file in the file system.
Reacted by Kamil Cukrowski, Tom Mittelstädt and sk8connection
Every file browser I know in every OS or app I know displays local time and date. I know of nothing else that displays dates as relative. This should at least be an option for Nextcloud as well for the many reasons stated above. Plus, it's less resources to figure out the actual date then it is to apply logic to determine a relative fuzzy date.
Is the tool tip hover option to get the real date not sufficient?
Any action which requires a mouse to get information limits that information to people who may have disabilities. Having an option to show the actual date and time would mean not alienating those people.
Please make this an option.
I have pictures in folders for every year. So for example in 2016 there are 5k pictures and they are all from "8 years ago". So finding a picture from a special date is kind of frustrating.
Activity
gpz1100 commentedon May 12, 2022
The problem with the relative dates is when they're older than a week. If today is may 13, telling me file is 8 months old doesn't tell me its date. Rather I need to think what was 8 months ago. Having a proper date stamp identifies the date immediately.
khcassidy commentedon Jun 3, 2022
Actual date option would be fantastic. To avoid arguments (US vs International) maybe ISO date format?
YYYY-MM-DD hh:mm:ss
I realize relative is friendly and maybe easier for some people but if you have a lot of files and need to know exactly when, relative is cumbersome/inaccurate to use. The fuzzyness of the relative date format for technical/scientific people is very triggering too. Generally people know today's date and if they need a file from 2 minutes ago or 2 days 3 hours 15 minutes ago, or the file they saved last week Thursday just after lunch time, they can figure that out easier with a proper time stamp then with the fuzzy relative style.
bbx-github commentedon Mar 13, 2023
We also would love to have this option. It could be a user option and the default could remain relative date format. This way the simplicity (argument #10258 (comment)) is kept.
I imagine two other options: absolute (according to locale) and custom (for choosing ISO format or different locale)
bbx-github commentedon Apr 3, 2023
I just realized using mouse over you get date and time according to your locale in a tool tip.
joshtrichards commentedon Sep 4, 2023
Is the tool tip hover option to get the real date not sufficient?
gpz1100 commentedon Sep 4, 2023
It would still be nice to have an actual time/date displayed, especially when trying to ascertain date/time of multiple files. Such option can be user selectable - use old view or new view with full date/time stamps.
khcassidy commentedon Sep 4, 2023
Problem I have with the fuzzy time is if multiple files are produced per day or per hour, you end up forever hovering over the column and scrolling to find the right file. I actually have changed some files to include the Date/Time in the name so that they are easier to find. If I try to find a file which I created this time last year and I create multiple files per day its a challenging exercise sometimes I resort to logging in to the server and finding the file in the file system.
gpz1100 commentedon Sep 9, 2023
ericloyd commentedon Dec 26, 2023
Every file browser I know in every OS or app I know displays local time and date. I know of nothing else that displays dates as relative. This should at least be an option for Nextcloud as well for the many reasons stated above. Plus, it's less resources to figure out the actual date then it is to apply logic to determine a relative fuzzy date.
ericloyd commentedon Dec 26, 2023
Any action which requires a mouse to get information limits that information to people who may have disabilities. Having an option to show the actual date and time would mean not alienating those people.
HKx2007 commentedon Feb 7, 2024
Please make this an option.
I have pictures in folders for every year. So for example in 2016 there are 5k pictures and they are all from "8 years ago". So finding a picture from a special date is kind of frustrating.
77 remaining items
ccsric974 commentedon Apr 10, 2025
khcassidy commentedon Apr 10, 2025
The Nextcloud Andriod app shows a hybrid of the two, Fuzzy for 7 days and older files have the date but no time.
OlmyApSennon commentedon Apr 17, 2025
susnux commentedon Jul 17, 2025
Resolved with #53937 for the solution described here: #29807 (comment)
For any further improvements, please open a new feature request.