Request: Function to Calculate Difference in Dates

[JMichaelTX]

@peternlewis, you have given us a rich selection of date tools in KM. I'd like to request that you add a function to calculate the difference between two dates. AFAIK, it does not exist.

This can be done fairly easy using JavaScript for Automation (JXA), but it would be very helpful, especially to those who aren't comfortable with scripting. I'd suggest something like this:

function DateDifference (pDate1, pDate2, pUnits)

where
   DateDifference = pDate2 - pDate1
   pUnits = choiceOf:  Sec, Min, Hrs, Days, Yrs, or standard format of Yrs:Days:Hrs:Min:Sec
   pDate1 & pDate2 formats supported:  ISO, English/Australian, American

Of course that is just a suggestion of what I think would be useful. You and others may certainly have different ideas.

Thanks.

---

From the wiki:

Current Date/Time Functions and Calculations

Here are some other date/time related tokens and functions:

[Editor: Plan to put in table with descriptions]

• DAY() (function)

• DOW() (function)

• GMTOFFSET() (function)

• JD2TIME() (function)

• MJD2TIME() (function)

• NOW() (function) (unixtime)

• TIME() (function) (unixtime)

• TIME2JD() (function)

• TIME2MJD() (function)

• %ICUDateTime% (token)

• %ICUDateTimeFor% (token)

• %ICUDateTimeMinus% (token)

• %ICUDateTimePlus% (token)

• %LongDate% (token) (local)

• %LongTime% (token) (local)

• %NumberDate% (token) (local)

• %ShortDate% (token) (local)

• %ShortTime% (token) (local)

• JulianDate

• unixtime in GMT

[peternlewis]

Keyboard Maestro currently has no support for parsing dates from text. This is on the list, but it is obviously somewhat challenging given the various date formats, even ignoring time zone issues.

But dates in unixtime or JulianDate are just numbers in seconds or days, so they can be differenced with normal subtraction.

[JMichaelTX]

@peternlewis

This is on the list, but it is obviously somewhat challenging given the various date formats

I fully understand, but it is a common problem many users face. That's why I suggested that it support 3 of the most common date formats.

@peternlewis

even ignoring time zone issues.

I think ignoring, or rather requiring that the two dates be in the same time zone, would be a very acceptable thing to do. Better to have something that works for 90%+ of the use cases than to have nothing because 100% is to hard to provide.

[suliveevil]

Convert natural language to unixtime may be the most important challenge, bigger than the calculate.