The odd bit, for me, is having to say "current application's" at all. It feels like I'm asking Mail, or Script Editor, or Finder to give me an NSString, rather than making one from the actual Cocoa Foundations library.
The "current application" constant refers to the application executing the script, but it's also the parent of AppleScript -- it might make more sense in that light.
*slaps forehead* See, I'm again forgetting that all of Cocoa (well, much of it) is open to me. can just call methods on the NSDate object directly, no casting necessary. The only tricky part will be converting back to text, so I can display or speak the information, but I can do much of this in ObjC, as you said.
Or ASObjC. You can use date formatters in ASObjC, and that's what you should be using to convert dates to text anyway.
set theNSDateFormatter to current application's NSDateFormatter's alloc()'s init()
theNSDateFormatter's setDateStyle:(current application's NSDateFormatterFullStyle)
theNSDateFormatter's setTimeStyle:(current application's NSDateFormatterShortStyle)
theNSDateFormatter's setDoesRelativeDateFormatting:true
set someDate to current application's NSDate's dateWithTimeIntervalSinceNow:(1 * days)
return (theNSDateFormatter's stringFromDate:someDate) as text
It seems like one could end up with the bulk of the logic and other internals all in ObjC, and only use AS for making the public-facing parts.
You could, but for many things there's no need to drop into Objective-C. Certainly not for converting to text or speaking results. OTOH, you can easily write your own Objective-C frameworks.