I'm trying to allow the user to input a date in numeric form and produce the same date in "word" form—so user enters "09/03/25" and macro produces "September 3, 2025." Here's what doesn't work:
Use "Prompt for User Input" to get variable "InvoiceDate" as a Date
Set variable DateString to %ICUDateTimeFor%InvoiceDate%MMMM d, yyyy%
That just gives me a "failed to evaluate" error. If I check the value of InvoiceDate in between steps 1 and 2 above, the value is 1756900800, which sure looks like a valid TIME value to me, but it seems likely that I'm misunderstanding the way that "InvoiceDate" variable is viewed by KM… right?
For some time I have been using a Subroutine (with some AppleScript code written by the great @ccstone) which parses dates from user input to whatever format I want to use.
So, there is a Subroutine that does the work which is called from your Macro. Here is a video showing what it can do. I started with the example you gave but it can do any format to any other format including phrases like "tomorrow" or "next Wednesday" or "2nd March 2024" or "23/8/2023"
I use is as part of a Macro I have to save receipts converting the date on the PDF receipt to a standard format that I want to use.
Here is the Subroutine and an example caller Macro. It will import disabled as a Macro Group but you can then move the subroutine to another Group of your choice.
EDIT: I realise on my Mac this is working with European Date Numeric Format (day/month/year) rather than US Date Format (month/day/year) but I assume that is just matching my Mac's date setting.
While @Zabobon's macro is the best answer in terms of date formatting flexibility, in terms of figuring out what's going wrong with your original approach, all I can offer is "seems to work here."
You didn't post your macro, so I can't tell why it didn't work, but I suspect it's got something to do with the variable inside your %ICUDateTimeFor... token.
@griffman, you make it look so easy... and I suppose it is, once you know how (I made an attempt that came very close but which erroneously used the TIME token and that’s where it all went wrong).
@peternlewis, I think this macro would serve as a very useful example in the Wiki.
I know I am not alone in finding that date formatting in KM can make one’s head spin somewhat, especially since the information is spread out between the Wiki and linked Forum discussions. The information is there but can take some piecing together and that’s when confusion can set in. #2c
Anyway, back to @griffman’s macro… Note that the year input is in the format YYYY whereas OP required YY. If that is truly what is intended for the range of dates required, YY could be converted to YYYY by adding 2000 to the year value (unless “00” is meant to represent the year 3000 rather than the year 2000).
However, since the input field in the prompt is set to “Date” (in the field’s dropdrown menu), the unix date that that provides would need to be converted first to isolate the year value. This would, I think, be less messy than applying a calculation directly to the Unix time value.
Aside from the question of YYYY versus YY, I presume, @anythingbutdave , that you have a particular reason to use the format MM/DD/YY rather than the international format YY/MM/DD, but if not, I would suggest the latter as the default always since, besides being the international format, it works best for filing to have the year value first.
Sorry, I forgot to mention that bit—yea, it's a lot trickier if you have to support a two-digit input year.
As an alternative, if a two-year date input were required, you could just set the input field to text, not date, then parse the text to format the year into four-digit form, then convert that into Unix time, and finally massage into written form. Something like this:
The downside to this approach is that you should really sanitize the inputs to make sure you're getting a valid date before proceeding. And you may have a time zone issue as you have to start at mid day to get the right date value out.
Basically, unless there's an absolute requirement for it, using a date-formatted input field with a four-digit year is a heck of a lot easier :).
I have that variable set to "Date" type, which (I assume?) automagically does the thinking and yields what would be the result of TIME(YYYY,MM,DD)… yes?
And thanks millions for the AppleScript routine, @Zabobon! I'll take a deep breath and try to get that to work for my case this afternoon.
I installed ccstone's subroutine and swapped in the "execute subroutine" action from the Caller Example for my failed attempt with ICUDateTimeFor. So I run the macro and enter the date in the dialog as I designed it:
If you post your macro, we can help you figure it out. Without that, though, it's tough. (Select your macro, click the Share button, select the KM Forum as the destination, then cut the text that appears in the new topic box and paste into a reply in this thread.)
Well, golly. (And sorry for the delayed response–it’s monthly invoice follow-up time so time for me to try this macro again.) @Nige_S’s solution made it happen!
As usual, I don’t understand why that solution worked, but I’m grateful for the shared wisdom! Happy Halloween and have a great weekend, all!
If you mean "compared to Chris's subroutine that @Zabobon posted" -- the sub uses Data Detectors and expects a text input, for example "31/10/2025" or "31st October 2025". But your prompt had the field format set to "Date", which returns "seconds since epoch" -- and the Data Detectors can't make head-nor-tail of "1761912000".
Set that prompt field type to "Text" and it'll work fine -- but you lose the spinners, built in error-checking, and so on.
If you mean your original macro -- hard to say without seeing it, but the only way I can generate that "failed to evaluate" error is by trying to use a "Set Variable to Calculation" action:
Partly for a laugh, and partly to impress with alternate solutions, you don't have to use ICUDateTime tokens for this, as you can use a KM action to call a macOS Shortcut to use an AI model, like this:
In fact, if you word the question correctly, you can even get it to do the conversion using a Unixtime numeric value (which is what the original question asked for) instead of a string. HOWEVER when I tried doing this with two different AI models, I got two different results, and I'm not sure why. Either some models are more accurate than others, or there may be two valid ways to interpret the question.
Hopefully KM will soon include a native action to let us access Private Cloud Compute, and maybe also ChatGPT and the Apple On Device Model also.
I appreciate your humour, but if you use the On Device model, you're using a local model, which doesn't necessarily burn dinosaurs because it uses whatever electrical source your house uses, which could even be solar power from your own roof.
P.S. In case you hadn't heard, there is a theory called the abiogenic petroleum hypothesis which says that some hydrocarbons underground are formed through simple high pressure mechanics. While it is true on small scale in the real world, most scientists (but not all) do not believe this theory on a large scale. But it's worth noting because most people have never heard that petroleum can be formed without biological sources.
Except aren't you using Private Cloud Compute in that screenshot?
The Private Cloud Compute running in an Apple data centre? Expending far more energy than local compute on your phone/Mac?
Inb4 someone says "But Apple's data centres are 100% green-energy powered" -- Yes, they are. But there's only so much green energy to go round at the moment, and every KW we use in a data centre is a KW that isn't being fed back into the grid and is having to be generated by other means -- chiefly gas or coal.
That's true, but I did say in my original post that I tried this with other models, which included the On Device model. So I did use the On Device model in my tests, I just didn't post all my results here, other than to say they didn't give the same answer.
I fully understand your point. Although you didn't say what region you are talking about. In many regions, there is no gas or coal. Like Iceland, Norway, France, Sweden, Switzerland, Bhutan, Paraguay, Nepal, Quebec, BC, Tasmania, Costa Rica, etc. These places are all 99% to 100% clean energy, if you consider nuclear to be clean, as most do.
That doesn't matter. Most regions (Australia being an obvious exception) are interconnected -- "waste" 1KWh of clean energy in France, that's 1KWh less France can export to the UK, and 1KWh of extra "dirty" generation required.
Grossly simplifying, obviously, but I think you get the idea.
Rambling nonsense hidden...
At the moment the true costs of AI are hidden by companies heavily subsidising its use in their attempts to grab as many users (and their data ) as possible -- analogous to the free/cheap "unlimited" cloud storage offers of a few years ago. When that ends there'll be some shocks in store -- Pro plans at $200/month will be referred to as "the good old days".
Local models might help, but mainly because they're considerably less powerful -- actual "per unit total cost of compute" is less in data centres than for local, for all the usual economies-of-scale reasons.
Back on subject -- I'm surprised the local model didn't do better at this, as I'd assume it has access to the same Data Detectors that are called in Chris's subroutine. Perhaps a bit of prompt massaging, maybe explaining the formatting part, will get it over the line?
I'm just using the in-house KM User Input prompt, so:
-- in case it's needed...