On Sep 10, 2009, at 6:43 PM, Sarah Reichelt wrote:
On Fri, Sep 11, 2009 at 3:26 AM, Devin Asay <[email protected]>
wrote:
On Sep 10, 2009, at 11:24 AM, Devin Asay wrote:
put tDate & 0,0,0,0 into tDate --
Oops! This should be
put tDate,0,0,0,0 into tDate
While I like Devin's method, I have changed to using:
put tDate,12,0,0,0 into tDate
By working with a default time of midday instead of midnight, you
avoid any possible daylight-savings change issues.
One slight comment about daylight-savings:
It is dependent on the computer clock setting running Rev.
If that cpu is not updated properly, it won't reflect the correct hour.
In an earlier email I noted the technique I use is to compare the
current midnight seconds to the previous to see if exactly 24 hours is
the difference.
if thisTime = prevTime + (24*60*60) then success
The catch is that you need to store the previous time, otherwise the
calculation will always be true since it is relative based on the
current clock setting.
In an office network, I experienced 8% of the computers were updated
by workers the wrong way and they did not notice the two hour
difference until the next day. Amazing.
In a side note that has nothing to do with daylight savings...
In another office, the very early shift of two workers faked the 6 AM
start by getting in at 7:30 am, changing the clock, doing some
reports, then switching back. I documented this by running an
AppleScript app on the Mac network server, and of course they were
fired.
Jim Ault
Las Vegas
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
