Hello,
They had a way of forcing the Web and Classic Web to comply with the Regional Settings of the Date configured on the server?
They work seamlessly on the desktop application, but not in both Web clients.
The M-Files Community will be updated on Tuesday, April 2, 2024 at 10:00 AM EST / 2:00 PM GMT and the update is expected to last for several hours. The site will be unavailable during this time.
Not sure if there's a way to follow the server settings but here are instructions for changing the date format in IIS: How to change date format in M-Files Web Access
Hello, Joonas,
Thanks for the answer, but I have already tried these settings and they have no effect after restarting the site, or after restarting the IIS service, even after restarting the entire server. It seems that the dotNet application is not respected by them. the result is that the date is always in the American format no matter what is here.
Any other suggestions?
Double-check that you have changed the regional settings for the system account on the server (and not only the admin user you are logged in as): How to manage date and number formats in M-Files. The desktop client uses the regional settings of the client computer, so the server settings might still be in the wrong locale.
Ah, it seems that at least the new M-Files Web is following the language preference of the browser.
Chrome running with English (United States) as the preference: dates MM/DD/YYYY
Chrome running with Finnish as the preference: dates DD.MM.YYYY
The mystery has been solved.
1. This applies to both Web clients, not only the new, but also the classic Web client
2. Not only Chrome, but all modern browsers such as Firefox, Edge, Safari, etc.
However, this is bad because I don't see a centralized way to enforce the expected settings and this will raise a lot of questions from end users.
I think it makes sense to follow the user preference since you could have users from different countries which each have their own date format conventions. And it's in line with how the desktop client follows the regional settings of the user's computer.
I suppose there are ways to manage browser settings centrally at least in a company environment but that's not an area I'm familiar with.
This is true if the company uses a homogeneous environment, such as Microsoft technologies (Windows-based desktop systems and Active Directory), unfortunately lately we increasingly come across customers who use different operating systems.
For example, Linux / Windows / MacOS and do not have a solution for centralized resource management, such as Active Directory.
It may be a good idea to at least configure web clients on the server, whether to use browser settings (decentralization) or to comply with the server's regional settings.
This is true if the company uses a homogeneous environment, such as Microsoft technologies (Windows-based desktop systems and Active Directory), unfortunately lately we increasingly come across customers who use different operating systems.
For example, Linux / Windows / MacOS and do not have a solution for centralized resource management, such as Active Directory.
It may be a good idea to at least configure web clients on the server, whether to use browser settings (decentralization) or to comply with the server's regional settings.