Skip to content

[Feature Request]: Add locale to dates #873

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
3 tasks done
JCC1998 opened this issue Mar 16, 2025 · 4 comments
Open
3 tasks done

[Feature Request]: Add locale to dates #873

JCC1998 opened this issue Mar 16, 2025 · 4 comments
Labels
Priority: Medium An issue that shouldn't be be saved for last Type: Enhancement New feature or request Type: Translations Modifies translation keys or translation capabilities. Type: UI/UX User interface and/or user experience

Comments

@JCC1998
Copy link
Contributor

JCC1998 commented Mar 16, 2025

Checklist

  • I am using an up-to-date version.
  • I have read the documentation.
  • I have searched existing issues.

Description

Hi!
I would like to ask to add locale to dates on the previews. Currently it's always using the english format, but for other languages, that might cause some confusion. English format uses month/day/year. In spanish, we use day/month/year.
For example, a file created on 1/12/2025, would mean 12th of January for english format, but it would mean 1st of december in spanish, which is almost 12 months apart. It would also cause "non valid" dates in cases like 31/01/2025

Solution

I would like to suggest to add a setting option inside the settings modal, with a selector to choose some options. At the moment I can think about 2 options: system_default and english. In case there's someone that has a different locale on their computer, they could still choose to visualize the file date in english format if desired

I would also like to add if I could tackle the solution of this request myself if it gets approved

Alternatives

No response

@JCC1998 JCC1998 added the Type: Enhancement New feature or request label Mar 16, 2025
@CyanVoxel CyanVoxel added Type: UI/UX User interface and/or user experience Type: Translations Modifies translation keys or translation capabilities. labels Mar 16, 2025
@CyanVoxel
Copy link
Member

Yes this would be great! It might be easier if the date and time settings were separated from the language used, as that would make it easier to select and a bit more free to customize for people who don't use the same date or time system associated with their locale. I imagine there could be one setting for the date format and another setting for the time format (12 or 24 hour).

If you're interested in working on this, the date label code is currently located in the update_date_label() method of file_attributes.py. It should be a matter of using the new setting options to format the dates here differently given their native datetime objects. I will note though that the settings system is currently undergoing some changes/finalizations, and I'd suggest waiting until #859 is approved and merged to work on this.

@CyanVoxel CyanVoxel moved this to 🍀 Backlog in TagStudio Development Mar 16, 2025
@CyanVoxel CyanVoxel added the Priority: Medium An issue that shouldn't be be saved for last label Mar 16, 2025
@Qronikarz
Copy link
Contributor

Just wanted to point out that the MM/DD/YY format is not English one, but American English. I also agree with the 24-hour clock setting.

Also also.
There is a standard of date format that was made specifically to solve the problem described in this topic. ISO 8601
https://www.iso.org/iso-8601-date-and-time-format.html
I think it makes it extremely clear what the date was/is/will be so it should make sense to include it as one of the options to choose when this feature gets done.

@JCC1998
Copy link
Contributor Author

JCC1998 commented Mar 28, 2025

HI!
Thanks for sharing your thoughts on this!
I do have implemented an "International" option, which uses dt.isoformat(sep=' ', timespec='seconds') and takes care of the iso format yyyy-mm-dd hh:mm:ss

About the locale in english, i set the locale as "en-EN", but I did not know that the locale "en-GB" did have the format as DD/MM/YYYY. So not really sure how to tackle it. I guess if your computer is using the en-GB locale, you can let the "System" option as the chosen in the settings, and have "English" as "en-EN".

At last, about the 24H option, I thought about having a checkbox with the label "24H", to be checked or unchecked. The problem i'm currently having is that if my locale does not use 12H format, even if I specify the format as "%I" (which is the directive specifying the hour as 12h format), using the directive "%p" does not display the text AM/PM. If I force the locale to be, let's say en-GB, the directive %p works fine. I don't want to change the locale, because it could mess the setting option already chosen, but not having it, makes it to display 03:40:00, when it should be 15:40:00 or 03:40:00PM. I was struggling because i didn't know why it happened, but I read the comment on stackoverflow that explained it: https://stackoverflow.com/questions/1759455/how-can-i-account-for-period-am-pm-using-strftime

Image

I wouldn't like to add the logic myself inside the code of the project to know when I should add AM or PM, so wasn't sure about what should I do, so I asked on the Discord, but I think I might have not explained myself enough
If you have any workaround, I would really appreciate to hear it, because I might need a different point of view of how to tackle it

Thanks in advance and thanks for taking your time to read this request!

@CyanVoxel CyanVoxel linked a pull request Mar 31, 2025 that will close this issue
8 tasks
@JCC1998
Copy link
Contributor Author

JCC1998 commented Apr 13, 2025

Old PR got closed because I made a mistake. New PR: #904

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Priority: Medium An issue that shouldn't be be saved for last Type: Enhancement New feature or request Type: Translations Modifies translation keys or translation capabilities. Type: UI/UX User interface and/or user experience
Projects
Status: 🍀 Backlog
Development

Successfully merging a pull request may close this issue.

3 participants