"send" in 24-hours

[Bill Vlahos]

Nicholas,

I don't think there are any specific concerns about very long send it times other than the minor ones I'm writing here.

1. You will have a problem when Daylight Savings time kicks in and out because it is counting the seconds not actually paying attention to what time it is.

2. Obviously if the program quits and restarts all pending sends are canceled so at startup you will need to set them.

3. You will want to make sure you are not accumulating unfinished sends. If you end up with more than one send message for the same thing each one will be processed.

4. To avoid these problems you could have a process that cancels all pending messages (say at midnight) and then recreates them. This would avoid the DST changes. It is surprisingly easy to accumulate pending messages. If you know how many you are supposed to have at any one time then check to see if there are more than that. But then you will have to figure out the ones you want to keep from the ones you don't. It is pretty easy to just cancel all of them periodically and then recreate them.

5. You want to avoid what I call "time creep". If you know the specific times of day then calculate the number of seconds from "now" to that time. That way you will avoid potentially adding a second or so on each iteration.

Bill Vlahos
_________________
InfoWallet (http://www.infowallet.com) is about keeping your important life information with you, accessible, and secure.

On Sep 8, 2011, at 10:09 PM, Nicolas Cueto wrote:

> Hello,
> 
> Two parts to my quandary, both relating to a school-chime stack I'm
> making -- it plays a "chime" sound-file at hourly-intervals (more or
> less) every weekday.
> 
> First, I recall reading once a warning about overly long "send"
> values. In my stack's case, the "send A in X seconds" values are
> either 60 minutes or 24-hours (converted to seconds).  What, if any,
> concerns should I have when using "send" with such large values?
> 
> Second, I've got my stack to work with this set of time-values:
> 
> 8:00
> 12:59
> 13:02
> 13:03
> 
> Obviously, I haven't tested a "send in 60 minutes" value. But, up to
> the 13:03-chime, no problems.
> 
> Now, I want to test the jump in time from one day to the next -- say
> between the 13:03-chime on Thursday and the 8:00-chime on the next day
> Friday -- but, obviously, I do not want to wait a whole day for that.
> I tried changing my PC's day-and-time settings, but no go.
> 
> If it helps, here is my script for calculating the "send" time
> difference between 13:03 and 8:00 the next day:
> 
> put "13:30" into tTimeA
> convert tTimeA to seconds
> put "11:40" into tTimeB
> convert tTimeB to seconds
> convert tTimeB to dateitems
> add 24 to item 4 of tTimeB
> convert tTimeB to seconds
> put abs(tTimeB - tTimeA) into tNextChimeTimeInSeconds
> send "play chime" to me in tNextChimeTimeInSeconds seconds
> set the cpPending of me to the result
> 
> 
> Thanks.
> 
> --
> Nicolas Cueto
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode