ISO date entry in build 2406 error

[twgonder]

My Windows 11 Access 2021 Build 2406 started to display an ISO entry date error that doesn't happen in the exact .accdb on Windows 10 Build 2405.



If I'm in a date text box and enter an ISO date as "2024.7.11" the date that shows for the control, during a stop in _AfterUpdate, as "11/07/202 ", the final digit of the year is missing.

Both laptops have the regional dates formatted as dd/MM/yyyy.

Can anyone confirm this behavior before/after the 2406 update?

Thanks

[Welshgasman]

Would that be because you have only entered one digit as month?
What happens when you enter 2 digits as I always would do?

[isladogs]

My UK date format is dd/mm/yyyy

Results from the immediate window:
?2024.7.11
2024.7 0.11

?2024/7/11
26.2857142857143

?2024.07.11
2024.07 0.11

?#2024/7/11#
11/07/2024

?#2024/07/11#
11/07/2024

[twgonder]

@ all I have a lot of code running for dates. There's a weird thing going on with date entry to a date bound field. An entry of "2024.7.11" won't trigger a Form_Error (#2113) however (Not IsDate("2024.7.11")) is True!
During testing, I've monkeyed with enough stuff, so that the truncation error went away, but as of yet I'm not sure why.
I'm not sure it's worth the time to get an old backup and figure it out.
Especially since it seems to be a new "feature" in the latest Access build that I have. But it does make me worry as to how the "new and improved" code will behave in older versions and builds.

@Welshgasman, one or two digit months didn't make a difference.

@isladogs the processing within the form seems quite different than what the immediate window does, especially for bound date fields

[twgonder]

About a month has gone by, and now the problem came back, truncating the final digit of the year.
In the immediate window I looked at the two properties (just after the stops), and one can see during the AfterUpdate procedure the value was changed.
It's odd, during my last testing the problem went away, then today it came back.
I'll reboot Windows, and suspect that if the problem goes away, it's something in the Access code that gets hosed, since I won't change my code just yet.

[twgonder]

Rebooting and decompiling didn't make a difference. Problem remains.
Should one be able to modify an entered value in the BeforeUpdate procedure without a problem?
I know you can't change to source data, but I would expect to be able to modify the .text value.
I think a similar thread touched on this, but it seems odd that the immediate value shows the correct values, and then changes in the AfterUpdate procedure.