I’m in my browser editing a Confluence document (https://www.atlassian.com/software/confluence). As stated above the date needs to be ISO formated (YYYY-MM-dd) (https://en.wikipedia.org/wiki/ISO_8601).
Unless you know about the Confluence web-collaboration tool then “a confluence document” can mean any number of things.
Just because you say ISO date doesn't mean you really are using one.
Providing real examples of real data is key to allowing others to help you efficiently.
There are a number of ways to go about this task, but this method was easiest for me to whip up.
-Chris
This one still uses AppleScript to create the dates, but it uses Keyboard Maestro to insert them into the Confluence document.
-Chris
Thank you. That’s exactly what I was looking for. Just curious, would that be possible without applescript at all, just using KM actions?
Edit: There is a little bug in the applescript which prevents some dates from being parsed correctly (for example christmas 2015-12-24). I just changed
tell _date to set _date to {text item **2**, text item **3**, text item 1}
to
tell _date to set _date to {text item **3**, text item **2**, text item 1}
and now it works perfectly.
Yes, but I don't want to take the time to figure out how to do the date math at the moment. The AppleScript was easy.
This isn't a bug per se – it has to do with how you have dates set up in your system prefs.
Which localization are you using?
-Chris
A solution and a question. The date arithmetic is simple (odd, but simple).
This seems to work. Cobbled together from some example's Peter has posted in various places, and some examples posted by others.
_Attempt to ({tab}, paste date + 1 day) fourteen times..kmmacros (4.2 KB)
Why does %ICUDateTimeFor%Time(Year,Month,Day)% return the date one day before Year,Month,Day? When I use "Day", the date is decreased by 1 day; when I use "Day+1" the date is kept the same. In this macro I used "Day+2", in order to increase the date by 1 day.
I don't understand this behavior.
Region: Austria
UI-Language: English
Format language: German
Date format: ISO format 
That explains it.
On my U.S. system the standard date setup is MM/DD/YYYY, and AppleScript requires that format to turn a string into a date-object.
I prefer YYYY/MM/DD myself, but if I change the system to reflect this some of my software gets flakey.
-Chris
Hey Kirby,
I think you may have missed the fact that TIME(Y,M,D) takes a GMT date/time string and returns a localized date/time.
Checking the KM function against date in the Terminal:
%Calculate%TIME()%
1444595856
date -j -f "%s" "1444595856" "+%Y.%m.%d %H.%M.%S"
--> 2015.10.11 15.37.36 (correct local time)
%Calculate%TIME(2015,1,11)% (We're not giving it a time, so it assumes Midnight GMT.)
1420934400
date -j -f "%s" "1420934400" "+%Y.%m.%d %H.%M.%S"
--> 2015.01.10 18.00.00 (correctly handling dst)
So:
%ICUDateTimeFor%TIME(2015,10,11,0,0,0)%yyyy-MM-dd HH.mm.ss%
On my system produces:
2015-10-10 19.00.00
If I give it the proper time offset (-6 normally -5 for dst):
%ICUDateTimeFor%TIME(2015,10,11,6,0,0)%yyyy-MM-dd HH.mm.ss%
2015-10-11 01.00.00
If I'm not needing the time I can just use -6 and not have to worry about fiddling with dst.
This is why I didn't want to bother figuring out the KM date-math yesterday.
The AppleScript gives me a simple localized date, and I don't have to fool with it.
-----------------------------------------------
set dateStr to "1/1/1970"
set dateObject to date dateStr
set newDate to dateObject + 10 * days
set newDateStr to short date string of newDate
-----------------------------------------------
Date-math in AppleScript can get goofy under some circumstances, but stuff like this is simple.
-Chris
1 Like
Indeed, and what a partial world of difference. Thanks for your guidance here. I have pressed my forehead to the fortress wall and walked the perimeter until I found a skeleton key hanging from the lock in this portcullis:
Accepting the limitation implied by "will generally work anywhere since at midday GMT, the entire world (almost) is on the same date", the following emendation to my all-KM macro should work "generally": replace the final Action with:
<img src="/uploads/default/original/2X/1/115538b59fb56972624656d5dfe32558a357a310.png" width="699" height="151"
It remains to make this work globally. Does the KM Calculation "GMTOFFSET()" accept any argument? Is there a way with KM to determine the GMT offset for a given date?
My thanks again. I shall, given the chance, show others these paths.
Hey Kirby,
As far as I know it is a straight function with no parameters and simply returns the GMT-offset in seconds of your computer.
%Calculate%GMTOFFSET()/(60*60)%
⇢ -5
Which is correct for CST with DST. (I was mistaken in my earlier post about the shell correctly managing DST.)
-Chris
No, GMTOFFSET does not take any parameters and only returns the current offset.
I'm afraid that unfortunately for the rest of the world using Keyboard Maestro, I live in one of the few civilised locations that does not have daylight savings (thankfully, contrary to our governments normal behaviour, they have not ignore three negative referendums on adopting daylight savings, even though they forced a "trial" on us after the first two - however I fully expect them to unilaterally ignore it and introduce it anyway in due course).
This luxury has led to me not being as aware and proactive with support for daylight savings issues as I should be.
2 Likes
Thanks for the answer. While it is not likely the more practicable course, I'd much rather daylight savings were globally abandoned than have software creators forced to layer an equant to their code to deal with it.
An "any time, any place" look up table for GMT offset seems a good project for ICU.
I’m pretty sure the Apple date system can determine the daylight savings offset for any timezone for any time. It’s just not something that is exposed in Keyboard Maestro.
1 Like
I don't undersand it either.
IF Day=1, then I'd expect TIME(Year, Month, Day + 1) to yield a day of 2.
@peternlewis, can you please explain this to us?
The TIME function takes and returns the values in GMT.
The ICUDateTimeFor token displays the localized time.
Thus, for TIME(Year,Month,Day) (which is in GMT), the ICUDateTimeFor displayed date in local time will be one less for anyone with a negative time zone offset.
Better is to use TIME(Year,Month,Day,12,0,0) which will give noon GMT time, and thus the same day in local time for pretty much everyone in the world (everyone with time zone differences strictly between -12 hours and +12 hours).
Nice, I use the date all the time.
In QKs I was able to determine the last digit of the day number and append either
st, nd, rd or th
i.e… 21st, 22nd, 23rd, 24th
basically an if/then loop, nothing fancy
I can’t quite figure it out in KM though.
Could you provide a bit of a ‘push’?
Greatly appreciated.
Use a Switch statement. The Switch statement can't be based on a calculation, but it can be based on text, and that can use the %Calculate% text token.
2 Likes
Great, thank you Peter -