future date testing

[Boaz Bezborodko]

>
> Message: 8 Date: Thu, 3 Jun 2010 12:40:26 -0400 From: Fairlight 
> <fairlite at fairlite.com> Subject: Re: future date testing To: filePro 
> Mailing List <filepro-list at lists.celestial.com> Message-ID: 
> <20100603124026.B1178 at iglou.com> Content-Type: text/plain; 
> charset=us-ascii Is it just me, or did Bill McEachran say:
>> > I need to test a routine that takes effect a month in the future.
>> > 
>> > Anyone know of a technique to fool a  filePro session into thinking the 
>> > date is a month into the future without actually changing the system date?
>> > I have a test setup configured using $PFDIR on the production box ... so 
>> > actually changing the date isn't feasible.
>> > 
>> > I was hoping I could manipulate the date by setting TZ in the test users 
>> > environment ... but I can only manipulate that by one day (unless 
>> > there's a syntax I don't know about).
>> > 
>> > Thanks.
>>     
>
> Set up Sun VirtualBox with a guest OS underneath, and set the date on the
> VM guest OS to whatever you need, and test the code on the VM.  Which is
> almost the same as saying, "Use another box for development," except it
> being virtual, you don't need extra hardware.
>
> There's not really a way to do it all on the same box.  It's not like the
> time is set in the alterable environment.  Time calls are going to resolve
> to the C function time(2), which goes by the system clock.  That
> methodology and the underlying mechanism is all or nothing.
>
> Using TZ -might- work, if you could create your own timezone file, -and- if
> setting an offset greater than ± 2359 is allowable.  I've never looked at
> the timezone files enough to know.  Bill Campbell might, though--he had
> fixes for daylight savings before most linux vendors did, when they
> switched the DST boundaries.
>
> Personally, I'd say use a VM.  If you use an OS that supports guest
> extensions, you can allocate shared folders, so you could actually mount
> the existing data directory and test on whatever you have already,
> in-place, if you need to, rather than just a copy.
>
> mark->
> -- Audio panton, cogito singularis,
Why not write the FPro routine to look at a declared variable instead of 
@td and then load that variable to @td+"30"?

Then, when you go into production all you have to do is remove the 
'+"30"' to have it read the present system date.  Al the rest of the 
routine should remain the same.

Boaz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.celestial.com/pipermail/filepro-list/attachments/20100603/bb9e85ed/attachment.html