SharePoint List Date Format Not Matching Site Locale Setting

Copper Contributor

Hi everyone,

 

I have just started experiencing an issue with a SharePoint List, where the date and time format doesn't match the column requirements. While our users can type out the date and time, it is inconvenient especially considering this issue only recently started showing itself.

 

When selecting a date and time in a list column, the format defaults to Month/Day/YYYY HH:MM AM/PM. This list, for the past few months, has always used YYYY-MM-DD HH:MM AM/PM for date format. The region setting at the site level is set to English (Canada), and our official national date format is YYYY-MM-DD.

 

What do you think the problem could be? Why would this suddenly start happening despite the list being used for many months without issue?

 

Column input:

pillbox_1-1677781680963.png

Column settings:

pillbox_2-1677781772950.png

Regional settings:

pillbox_3-1677781909392.png

 

 

24 Replies

@pillbox Only you are facing this issue or all the users using this SharePoint site/list are facing this issue?

 

Did you change any language/region settings for your user profile which might cause this issue?


Please click Mark as Best Response & Like if my post helped you to solve your issue. This will help others to find the correct solution easily. It also closes the item. If the post was useful in other ways, please consider giving it Like.

For SharePoint/Power Platform blogs, visit: Ganesh Sanap Blogs

@pillbox 

 

Long reply - lots of frustration with this issue here.

 

We also had this issue pop up out of nowhere about a month ago.  We are located in Canada and require the yyyy-mm-dd format, but SP lists started defaulting mm/dd/yyyy. It impacts some users, but not all users.  No regional, locale, date, language or format settings had been changed in SP, Windows, Individual Microsoft Account, or Individual Delve Settings in m365.  Our SP regional settings are set to English (Canada), while our regional format in Windows, m365 and Microsoft accounts are defaulted with English (United States), this setup worked fine until recently.

 

We have had an escalated case open with an MS engineer since the issue started, and after multiple streaming sessions with various engineers, the issue remains outstanding and unresolved.

 

As part of the troubleshooting process, we changed every regional, language, date format setting possible in SP, Windows, Microsoft Account, and Delve Settings in m365 and tried various combinations in an effort to make this work.  Having no impact whatsoever, I restored all my settings back to what they been originally (this was two days ago) and my lists still failed at that time. 

 

Lo and behold, this morning my list settings are correct, though other users are still experiencing the same issue. For one of these users (who has been our IT lead with MS on this case), we have changed all of their settings to match what I currently have and will test it tomorrow to see if 24 hours is needed for all updates to process?

 

One last tidbit:  my login can now enter dates in the lists correctly.  If however, I log into SP with the admin login, the list problem occurs for them. So that rules out local windows settings and anything to do with sharepoint.  the only difference between those two accounts is the m365 delve settings and the microsoft account settings, the admin login has the regional settings of English (Canada) in both...

We are not going to change any of the admin login's info as we will leave that as it has always been until this 'bug?' is fixed or until we confirm via testing with other users that the fix is in fact to remove any reference to English (canada) except in the SP regional settings.

 

 

Hi Ganesh,

We have not changed any language or region settings at the user-level. The site, list, user, endpoint, and browser have not seen any changes prior to and during the discovery of this issue.

I've confirmed the regional format settings under the affected Microsoft accounts are also set to YYYY-MM-DD.

Hi @Jesse_Dan,

 

I appreciate you spending the time to share your findings! We are also located in Canada and require the YYYY-MM-DD format.

 

I think the difference between your account and the admin account relating with Delve and M365 account settings is promising. Are you able to share with me the settings for M365 and Delve which seemed to have resolve the issue?

 

Our M365 account settings region is set to English (Canada) with the YYYY-MM-DD format.

pillbox_0-1677865710085.png

 

When looking at the Delve region settings (which forwards you to SP user profile settings), our region settings are following the site configuration.

pillbox_1-1677865795183.png

@pillbox  here you go.  Also - when I changed my settings back to below for my user the issue did not resolve that day, it wasn't until a couple days later ... who knows if that had any bearing at all.

 

Here are the settings for my user in my MS account:

Jesse_Dan_0-1677866493212.png

 

Delve settings, note I have changed the Region Settings to tbe 'Always use my personal settings'

 

Jesse_Dan_1-1677866600939.png

 

Settings for the admin user that does not work:

 

Jesse_Dan_2-1677866720427.png

 

Jesse_Dan_3-1677866803180.png

 

Thanks @Jesse_Dan,

 

I've updated my settings to yours exactly (other than timezone) and will monitor. It is interesting to me that your Delve region setting is set to United States as their date format is MM-DD-YYYY.

 

If I don't see any changes by end of Monday I will try Canada and continue to monitor.

I am reasonably certain it did NOT used to be like that ... we changed so many things so many different times, I likely neglected to change it back to whatever it used to be (happy coincidence?).

Looking at those screenshots, I see that at one point I updated my MS Account profile to be United States, but changed the format to be yyyy-mm-dd instead of the detault US MM-DD-YYYY.

IDK - good luck though!
Quick update; no combination of region settings has had any effect in solving this issue. Selecting time and date in a list column still defaults to USA date format regardless of region settings.
Yeah, very irritating. Just started seeing this issue and we are also based in Canada. At first I thought it would be PC settings conflicting with SharePoint, but both are set to Canada. I also checked Edge's Language Settings and changed the "Share additional operating system region" to "Always (not recommended)", and that made no difference.
Sorry it didn't work for you. We have confirmed these settings work in our environment for more users than just me :). Our IT lead on the case had one and only one difference from my user and that was the date format in the MS account's regional settings. They had already switched it to English (United States), but their format was still mm/dd/yyyy. They updated the format to be yyyy-mm-dd, waited for an hour, and then they were able to enter dates in the lists without issue - bizarre.
We've also started to have this exact issue. Started with a couple of users, now seems to be impacting more. Haven't found a pattern yet.
Thanks for your screenshots @Jesse_Dan.

When you set your MS account and Delve settings as per your screenshots, did the dates on lists display as YYYY-MM-DD or did they change to MM/DD/YYYY? I have an account which recently started experiencing this issue on a SharePoint site set to use English (Canada) and when I made my settings match yours, I was once again able to enter dates using the date picker without error. However, they all displayed in the list as MM/DD/YYYY.
For me they now display as MM/DD/YYYY. That said, for the users that continue to experience the issue, they display as YYYY-MM-DD.
I should add that restoring the date picker functionality was our primary concern, as our lists are very heavily used and having end users manually input yyyy-mm-dd into the date fields was onerous and resulting in many entries with yyyy-dd-mm. Secondly we needed to be certain that the flows/approvals that triggered off the lists correctly interpreted the dates, regardless of the format displayed. Thus far, the 'fix' is working and satisifes all of the above, so we are just going with it. My concern is the other shoe is going to drop at some point when this 'bug' is fixed and we may be forced to revert to old settings.
I'm having the same issue. Also in Canada. Also seeing American MM/DD/YY format instead of yyy-mm-dd format that we have used for years. I don't recall the date-picker popup until a month or so ago. Now the popup is there and changes the date field to the wrong format and prevents saving the date (incorrect fromat). if a user (understandibly) mistakenly beleives that the popup can be used to select a date, they waste their time and pull our their hair until they have been given instructions to "press esc when the popup appears and manually type the date in yyyy-mm-dd format". This is a rediculous bug. Obviously only techs in USA tested the changes they made to date picker before implimenting. We need this fixed. Very frustrating for all my non-techy users and techy users alike.
I am able to get around this issue by restoring classic view on the list. I will impliment this tempoarily until MS can get their poop in a group and fix the datepicker in modern pages to respect the locale for the site. For certainty, datepicker works correctly and respects the locale settings on classic view. It is ONLY the modern view datepicker that has a bug. Thus, it is not anything to do with the local user, site, or global settings. Its a bug introduced by the programmers in the USA that did not test for different locale's than USA when they started rolling it out a couple months ago. Hopefully they just roll back the update or fix the bug promptly.

Has anyone experienced any changes in behaviour when using Chrome? Suddenly the date picker is working in Chrome on every computer we've tested. But Edge still experiences the same error. Microsoft is trying to close our ticket saying that this shows it is a browser issue and not a Microsoft 365 problem.

@mdatwork ridiculous for Microsoft to say that's fixed when Edge is their own browser!

I Second the Hell outta that one!