Reason, I need to know in order to verify that the time differences “Algorithm” below works.
Thanks
set td to (current date)
-- setting the End date
set hours of td to 2
set minutes of td to 30
set seconds of td to 1
log "today: " & td
-- setting the start date
set yd to td - 1 * days
set hours of yd to 1
set minutes of yd to 40
set seconds of yd to 0
log "yesterday: " & yd
if yd > td then error "I can't have that start date is after end date!"
set dayDiff to (td - yd) div days
log "daydiff: " & dayDiff
set hoursStart to (hours of yd)
set hoursEnd to (hours of td)
if dayDiff = 0 and hoursStart > hoursEnd then set hoursStart to hoursStart - 24
set hourDiff to ((dayDiff * 24) - hoursStart) + hoursEnd
-- We should never have to borrow a day, to get a surplus of hours
-- if end date comes after start date, even if comes just a minute after!
set minDiff to (minutes of td) - (minutes of yd)
if minDiff < 0 then
-- short of minutes , must borrow an hour
set hourDiff to hourDiff - 1
set minDiff to minDiff + 60
end if
set secDiff to (seconds of td) - (seconds of yd)
if secDiff < 0 then
-- short of seconds, must borrow a minute
set minDiff to minDiff - 1
set secDiff to secDiff + 60
end if
log "TimeDiff: " & text -1 thru -2 of ("0" & hourDiff) & ":" & text -1 thru -2 of ("0" & minDiff) & ":" & text -1 thru -2 of ("0" & secDiff)
Problem was, when the day diff was zero, if the start hour, then were greater than the end hour, then the math didn’t work out, since we then would be left with a negative number of hours.
The easiest fix, was to subtract 24 hours in this case, from hours start, since that leaves us with positive numbers when computing the minutes if the minutes underflow.
I am not converting from 12 hours to 24 hours, I just studied a general approach to finding the difference between two times that may occur on different dates, using more primitive date-types than the applescript date. I wondered while doing that if the hours of the hour property was the same.
And you can’t just subtract 12 hours, without checking if either the time is > 12 hours, or the 12 hour clock’s time string for “pm”.
Here is the correct AppleScript way for finding the time difference though.
set td to (current date)
-- setting the End date
set hours of td to 11
set minutes of td to 30
set seconds of td to 1
log "today: " & td
-- setting the start date
copy td to yd
set yd to yd - 1 * days
set hours of yd to 23
set minutes of yd to 40
set seconds of yd to 0
log "yesterday: " & yd
if yd > td then error "I can't have that start date is after end date!"
tell (td - yd)
set hourDiff to it div 3600
set secRest to it - hourDiff * 3600
end tell
set minDiff to secRest div 60
set secDiff to secRest - minDiff * 60
log "TimeDiff: " & text -1 thru -2 of ("0" & hourDiff) & ":" & text -1 thru -2 of ("0" & minDiff) & ":" & text -1 thru -2 of ("0" & secDiff)
I was really looking for a general way to do it, and I guess there are options out there, I found out that I can subtract FileMaker Pro timestamps, so this is maybe superfluos, but I need something for spreadsheets as well, and there something like the first script may be feasible, when converted to an Excel function for instance. (Having columns with hours, minutes and seconds, and maybe a start and end date.)
Yes, that I did to avoid the mod operations, I also deliberatly avoided using the hours and minutes constants, because I think their absence makes it easier to understand the code on the fly. Especially, when I haven’t looked at it for a while.
It is the day of the unusual stuff today, I also did something unusual, with the “general” approach:
I find the lines:
if dayDiff = 0 and hoursStart > hoursEnd then set hoursStart to hoursStart - 24
-- this is needed when the daydiff is 0
set hourDiff to ((dayDiff * 24) - hoursStart) + hoursEnd
a lot more readable than:
if dayDiff = 0 then
-- this is needed when the daydiff is 0
if hoursStart > hoursEnd then
set hoursStart to -(hoursStart - 24)
else
set hoursStart to -hoursStart
end if
else
set hoursStart to ((dayDiff * 24) - hoursStart)
end if
set hourDiff to hoursStart + hoursEnd
I thought you had solved all of this with the Sunset cal and Nigels help. You know one thing my calendar is showing 24 hour clock and I don’t like that. Trying to solve that too.
That is correct, you can’t go wrong, as long as the dates are ordered, so that the end dates ends after the start date, and the two dates are alike.
As long as the dates are after 1 january of 1970, you can do the same with the unix date command, (convert two dates to seconds, subtract them with expr, and them format back to hours minutes and seconds.
I guess you can do it in FileMaker too (but I haven’t figured it out yet,) I guess you can do the same in Numbers, and Excel too. (Thing is, sometimes it is easer to just enter hours, minutes and seconds in different spread sheet columns, and that is what this really have been centered around, and also Filemaker for that matter, because there at least I enter time and date in separate fields.
What if instead of using the fixed start date, create your own start date like 2000. Never mind me I don’t know what I’m talking about but just throwing out things so disregard if not useful.
Anyway, darn forgot what I was working on! Might be getting close to to sleep time.
In the military, I was the best snow shoveveler they had :). Cleared the snow out by the next morning. But, don’t tell anybody but my friend came along with the snow shovel before anybody came to work :D.
ps. I blew their minds how much snow I used to move.
Edited: in fact, I think the Colonel wanted to give me a medal!!!
I should mention that Nigels way of computing a time difference is probably more accurate than mine, I think that using multiplication instead of modulus, may make my approach to computing a time difference with AppleScript, loose a second now and then, I am not totally sure of it, but I have taken height for the possibility that it may happen. In the context I am going to use it, a second doesn’t matter. but it may be important to know of, in other circumstances.
Here is my favourite time system kel, someone has actually turned it into a religion:
They, in that article are schizos. Just like us! No but seriously. The more accurate you can get is the best. I’ve used algorithms that seemed like they would work, but one month or day I forget, it was off by just a few time spans. Your’s were very accurate though and I haven’t seen differences between that and the international ones.
The great thing about your data is that it’''s accurate even more accurate than the current app that I was using. And you don’t need to look up the info in tables. on the internet As I said there was that one day when it was wrong and yours was right and that opened my eyes.
Besides that, your calculations do not depend on tables taken from the internet. I know you had a little help from others such as Nigel, but piecing together all the parts is a major part of the job. And a great job it does. I’d rely on your calculations more than any other person and can see in your work the quality that anyone can rely upon.
I Still haven’t put it all together in the Calendar, but use your calculations as references. I compare your outcomes to some dates and as I have said, you have proved them wrong. Maybe soon on my part when I do make a Calendar I’ll inform you.
I have pondered whether the multiplication and divisison approach is more inaccurate than using mod, and my conclusion is that may be so, if the number of seconds in difference between td and yd are enormous.
You should really thank Nigel, a lot more than me, or at least no less, for the Sunrise, Sunset things kel, he did write the original port of the script, unsolicited, and he got all the math right, and it is the accuracy of the math you are addressing here, and not the UI.
And it was that other guy that made the algorithms, and if you aren’t talking about the sunset/sunrise, but about moon or other tables, then, I have just used algorithms I have found, and implemented them.
