In our software we occasionally need to pass a date and time value in some sort of String format which may end up being used in SQL and converted back to a DATETIME.
I wish it weren't so, but it is what it is, there's a legacy aspect to this that we cannot change.
So in order to avoid problems I've insisted that if this needs to be done, people need to convert the date and time value to the "yyyyMMdd HH:mm:ss" format
But of course there's always that one developer who "forgets" to do this, and VB is so darned forgiving....
Dim startDate As DateTime
'something here sets it to an actual date and time, say the 26th of September 2024 11:12:13
Dim sStartDate as String
'This is what they SHOULD be doing:
sStartDate = startDate.ToString("yyyyMMdd HH:mm:ss")
'But this is what they actually did
sStartDate = startDate 'leaving it up to VB to "kindly" convert it to a Short Date/Time format
Because our clients are all UK/Irish this has never been a problem and this particular piece of code (or something very similar) has worked for hundreds of people without a glitch. As a result of what they actually did the string becomes "26 Sep 2024 11:12:13" and when this gets sent to a SQL server and converted to a DATETIME it's perfectly fine.
Years pass
Suddenly we get a support call from a client where this isn't working. When we investigate the problem we find that the date and time value is not converted to "26 Sep 2024 11:12:13", but instead it's converted to "26 Sept 2024 11:12:13". And SQL throws a hissy fit.
So what we need to do is obvious. I need to rap somebody's knuckles, fix the code that doesn't explicitly set the date format during the conversion, fix the SQL Stored Procedure that accepts the string value to handle "June", "July" and "Sept". But I'm left with a question...
My question
Where is this configured on the user's PC? We looked at their regional settings (It's a Windows 11 machine) and they look the way they should.
There doesn't even seem to be a setting that would produce 26 Sep 2024? Like a "medium date format"? A setting that might produce "26 Sept 2024" instead?
I can't believe I need to ask this question - and I had a bit of a google but I can't find anyone with the same problem on Windows. Not on Stack Overflow nor elsewhere. If this is a duplicate I apologise... I didn't find any original question that deals specifically with this issue in Windows 11 and/or Visual Basic.
So after a lot of Googling and searching I think I finally have an answer and it's all due to the standards set in the "Unicode CLDR Project"
It may be very new to us who are suddenly subjected to Windows 11 24H2, but in fact this standard has been around for years. If you go googling for "September changed from Sep to Sept" you will find people coming up against this issue for years on many different platforms. I found one such complaint dating back to 2015 and who knows there may be earlier ones.
Long story short: With regard to this standard, Microsoft is actually "late to the party". Others implemented it a LONG time ago.
All we can do is ask our clients to delay applying Windows 11 24H2 until we get around to fixing our software so it can handle this properly. Thankfully this turned out to be not as big a deal as I feared.
My apologies to anyone who came here hoping to find a "fix" but the only thing I can do is provide the answer to the question as stated. This is why it happened. We have to learn to live with it.