Changing date format in CalendarWidget100

[Jim Ault]

On Sep 10, 2009, at 6:43 PM, Sarah Reichelt wrote:
> On Fri, Sep 11, 2009 at 3:26 AM, Devin Asay <devin_asay at byu.edu>  
> 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