Two pieces of AppleScript: one works, one fails—why?

I simply love it. That’s “I know better than you what you want” at it’s best. Written out, the script does this

set target to "Friday" & " " & 3 & " " & "May" & " " & 2021

which this lovely language encourages to create a list:

{Friday, 3, "May", 2021}

Never mind that the first value is already a string - oh wait, it is not. Of course, we mere mortals would expect weekday to be just a sequence of characters. Not so Apple in its wisdom: It is a constant. (The same goes for the month “name”, btw). Only if you add as string (to wday or at the end of the string) will you get a string. I can understand that @Stephen_C

I knew I’d get that sort of response from you! It did make me laugh.


Yes. Sorry. Apparently I can type or think, but not at the same time…
I was thinking about coercing lists to text, which you might do by adding ‘as string’ or ‘as text’.
AppleScript will silently coerce list items that are not text to text, but there are things that it cannot convert, and you’ll have an error.
So i wanted to make clear that the list you are building in your script contains things that are not text. Luckily, AppleScript constants can be coerced to text, so all seems well.

But try it with a list where one item is a record, and you’ll get an error.
I hope I expressed myself more clearly this time.

Warning: This post has no relation whatsoever to DT!

weekday of date returns a constant (Monday, Tuesday etc.), not a string. And apparently (and contrary to my expectations), this constant is not silently coerced to text. It just builds a list if you have this constant as the first term of a collation.

The wonderful thing (ok, it is anything but) is that weekday of date as string actually returns a string, but in the system wide language setting. So the constant Monday is converted to the string “Monday” in any en locale, but to “lundi” in any fr locale, “Montag” in any de locale, and yí something in Mandarin. You as a programmer can’t influence this. So if you want to work with french weekdays on a machine where the system wide language is set to Mandarin … good luck.

As a side note: In “the other scripting” language, you can just set the locale and the format you want the values to be (short, long, numeric, two digits - whatever). Regardless of system settings.

1 Like

I’m grateful for everyone’s comments which are, of course, interesting. However, in order that the thread is not completely derailed :grinning: I’d be even more grateful if someone could tell me why, when I’ve included the amendment mentioned by @cgrunenberg, the second piece of code works using the default input but not with any other input. I assume if I’d been doing something stupid others would by now have pointed it out - so I’m still completely baffled.


This is working as expected for me…

set dAnswer to "01/07/2021"
set userEntry to display dialog ¬
	"Enter the link date as DD/MM/YYYY" default answer dAnswer
set userDate to text returned of userEntry
set linkDate to date userDate
set wDay to weekday of linkDate
set dateDay to day of linkDate
set dateMonth to month of linkDate
set dateYear to year of linkDate
set targetRecord to (wDay & " " & dateDay & " " & dateMonth & " " & dateYear & ".md") as string

tell application id "DNtp"
	if not (exists database "11") then
		open database "~/Databases/Misc and Test Databases/Dummy Databases/11.dtBase2"
	end if
	set foundRecord to (search "name:" & targetRecord) in (database "11")
	set theUUID to uuid of item 1 of foundRecord
	return theUUID
end tell

Noting the foundRecord line could be written in different ways. I wouldn’t - and did not - use the contents… whose name construct.
And no, I didn’t error trap the open database line :stuck_out_tongue:

Not here, no. When I run

weekday of (current date) as text

I get “Friday”. According to you, it should be “vrijdag”, as I’m running dutch.
And no, placement of braces doesn’t matter.

Constants are not localised when coercing them to text. Sorry.

Thanks so much for that…but I still get the following error:

error "Can’t get item 1 of {}." number -1728 from item 1 of {}

I must be doing something stupid. Let me look at it yet again. The only material difference now between my code and yours is my line:

set theDatabase to open database "/Users/stapp/Documents/DevonThink/Diaries.dtBase2"

with the consequent change in the following line.


That error would be because it’s not finding anything.

Yes indeed. :frowning:


	if foundRecord ≠ {} then
		set theUUID to uuid of item 1 of foundRecord
		return theUUID
	end if

This error traps it for no results.

But why does it not find a record that clearly exists?


Well… from the posts on this thread, it’s not clear it does exist. :wink:

From my database 11…


I can see the damn thing! :sob:

It’s OK - leave it with me: I’ll get there somehow.


Post a screencap of the file you’re seeing in the item list.

Or better, the Info pane’s top sections including Location.

And I was searching for 31/05/2021.

The thing that totally baffles me is that if I leave the answer as the default it comes up with the correct UUID (including if I input that date manually) but if I input any other date it fails.


Edit: to remove more than one me: no wonder, in the circumstances!

Have you tried 5.31.2021?

Yes - and again just now: same error. Please don’t spend too much of your time now on this, I’m getting quite embarrassed about the whole thing! If you have any more ideas, at leisure, just return to the thread when you have time.


No need to be embarrassed.
We’ve all had our :thinking::face_with_symbols_over_mouth: moments in automation.
I’m sure we’re just missing some little detail.

In the replies, is the expected filename, i.e. with the expected date, reported?

1 Like

Thanks for the good cheer! Am sure it’s something quite stupid but have been hammering away at the wretched thing for 24+ hours without getting anywhere!

Let’s relax and come back to it some time. Thanks so much for the support, as usual.