Don’t despair. A date object is displayed using the system’s locale settings. The constants are not coming from that displayed text. They are separate properties of the date object. The display is not the object (“Ceci n’est pas une pipe)”
And there is a way to get a date object to display in a language that’s not the system’s.
Now my brain hurts (and the listing you linked to messes up UTF-8 characters 
But I see that you had your hands in this AppleScript solution, too – better to think twice next time I comment a post of yours
Here’s what I’d do in JavaScript
const locale = "de-AT";
const weekdayFmt = new Intl.DateTimeFormat(locale, {weekday: "long"});
const monthFmt = new Intl.DateTimeFormat(locale, {month: "long"});
const today = new Date();
today.setMonth(0); /* change month to January to get a more interesting output */
const weekday = weekdayFmt.format(today);
const month = monthFmt.format(today);
console.log(`It's a ${weekday} in ${month}`);
which tells me It's a Samstag in Jänner, which is a really nice touch for our Austrian friends. I find this approach a tad more convenient and robust than fiddling around with locale files that might be stored in another location in a new version of macOS (and/or change the order of lines or whatever).
But I agree, it is feasible. And date/time are a never-ending source of joy and fun:
Dankjewel!
I have the impression that @Stephen_C and @BLUEFROG are using different ways to search for the record: @Stephen_C does something with (contents of …) whereas @BLUEFROG uses search. Could that make a difference?
Just a wild guess: one of those literal spaces may not be only a space. Replace them with constant ‘space’ [heh]:
set theTarget to wDay & space & dateDay & space & dateMonth & space & dateYear & ".md" as text
Sorry, catching up with everything…
Not now - see this earlier post in the thread.
The reason I think that’s not the problem is this: why the devil does it work if I delete the default date in the input dialog and then input that default date manually, but then if I input any other date in place of the default it fails? Clearly the default date must be being processed by the code in exactly the same manner as any alternative date, surely? So why does one work and the other fail?
Am slightly battered now but tomorrow if I get the chance I’ll try with many alternative dates (I have thousands of records - covering every day of the past 40+ years - with which to experiment!) to see if any of them work (although I’m not optimistic). Something completely bizarre is going on and I simply don’t for the moment know what it is. I don’t think I’m being completely stupid but am beginning to wonder!
Stephen
You didn’t identify what’s not working
For myself (Canadian)
Script 1 generated targetRecord Thursday 1 July 2021.md
Script 2 generated targetRecord Thursday 7 January 2021.md
Stephen, are you running the script from Script Editor or from within DT (as an embedded script in a rule)? If from Script Editor, could you please post a replies window as Jim did in this response?
Sorry - what happens is that the first script finds the UUID of any record - whether that of the default answer or that of any other date I input in place of the default answer. (In other words, it does exactly what I want.) The second script will always find the UUID of the record shown as the default answer (even if I change the default answer in the script to a different date) but will never find the UUID of a record with a different date which I input manually (even if that record exists and can be found by changing the default answer, in the script, to the date of that record).
I’m running from Script Editor for debugging purposes and posted here the response given in the editor when the second script fails.
Edit: removed edit for further testing of script.
Edit and correction: script now finds the record if default date is 01/07/2021 but fails on most (all?) changes to that default date (even though the relevant records exist).
Stephen
There may be a little good news. Following a lot of cutting and pasting of results from Script Editor and checking manual search results in DT it appears as if the problem may be resolved by dispensing with the .md extension when assembling the file name in the script. If that is present (even when manually searching in DT) entries seem not to be found. Removing the extension produces promising looking results from the script (in that the script actually produces a UUID). I still need to check that the UUIDs produced are those of the actual, relevant entries.
For those who have assisted, many, many thanks. I guess the problem is that I have 18,000+ markdown files all divided into relevant years and with a generated table of contents for each year. (The latter being the reaon I need to check that the UUIDs are not being produced from the tables of contents.) That means I have an awful lot more records than those of you who have been kind enough to test.
Life has to go on…I’ll do some more testing later. In the meantime, huge apologies for the length of this thread and the work generated for all who have tried to help.
Stephen 
No need to apologize!
Just the other day I belabored my parents with a diatribe on some changes I need to make to our documentation. When I was done, my father astutely said, “Sometimes it really helps to jus talk things through out loud.” 
PS: Are you showing extensions via DEVONthink’s Prefererences > General?
Jim, you are always so kind and supportive: I can’t express how much that’s appreciated: thank you.
Yes - Show filename extensions is checked.
Stephen
You’re very welcome
Thanks for checking that out.
Yes, excluding the extension from the string would be a good idea.
I would also suggest using the search form I mentioned. It’s basically the same as typing in a search in the toolbar search field, just tell DEVONthink to do it via AppleScript. You can edd search prefixes in the query to target Markdown files, just as you would in a normal search, so…
set foundRecord to (search "name:" & targetRecord & " kind:markdown") in (database "11")
would only return matching Markdown files.
Yes, I’ve done that, thanks.
That’s most helpful, thanks.
I think, at the end of this exhausting and exhaustive thread, we are home and dry…at last.
Stephen
This is insanely helpful information to have at hand–and I know I am never going to find it again when I actually need it…
Now where might I put a piece of information I know I’ll need to find again… 
Wait…there’s an app for that! 
Stephen
Also, it is unfortunately inaccurate. You should consider the later post(s) by @alastor933 for bookmarking (if you are interested in the date issues, that is) rather than mine.
you people I really enjoy being a part of this forum 
When I read this for the first time a text came to my mind, obviously forgot to post it.
It’s Über die allmähliche Verfertigung der Gedanken beim Reden by Heinrich von Kleist.
Here’s a translation On the gradual formation of thoughts in the process of speech.
And I have book here by Susan Sontag (her journal) of which the German name translated back to english is “I write to find out what I’m thinking about”. I work a lot to get myself to write in such away, using DT and paper notes and whatnot, but yes, I make my finest points and arguments when I’m speaking to others: speaking out loud in the presence of others, but it also works in speaking things out loud for yourself.
So I have to either speak it out loud for me and then write down what I said, or make this start to work when I write (which it hasn’t yet).
On the other hand, reading your quote and references and thinking made me write this forum post, and in it is a new thought I never had before. Or at least, not as clearly as before. But I wasn’t speaking, I wrote.