<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<blockquote type="cite">
<pre wrap=""><div class="moz-txt-sig">Message: 8
Date: Thu, 3 Jun 2010 12:40:26 -0400
From: Fairlight <a class="moz-txt-link-rfc2396E"
href="mailto:fairlite@fairlite.com"><fairlite@fairlite.com></a>
Subject: Re: future date testing
To: filePro Mailing List <a class="moz-txt-link-rfc2396E"
href="mailto:filepro-list@lists.celestial.com"><filepro-list@lists.celestial.com></a>
Message-ID: <a class="moz-txt-link-rfc2396E"
href="mailto:20100603124026.B1178@iglou.com"><20100603124026.B1178@iglou.com></a>
Content-Type: text/plain; charset=us-ascii
Is it just me, or did Bill McEachran say:
</div></pre>
<blockquote type="cite">
<pre wrap=""><span class="moz-txt-citetags">> </span>I need to test a routine that takes effect a month in the future.
<span class="moz-txt-citetags">> </span>
<span class="moz-txt-citetags">> </span>Anyone know of a technique to fool a filePro session into thinking the
<span class="moz-txt-citetags">> </span>date is a month into the future without actually changing the system date?
<span class="moz-txt-citetags">> </span>I have a test setup configured using $PFDIR on the production box ... so
<span class="moz-txt-citetags">> </span>actually changing the date isn't feasible.
<span class="moz-txt-citetags">> </span>
<span class="moz-txt-citetags">> </span>I was hoping I could manipulate the date by setting TZ in the test users
<span class="moz-txt-citetags">> </span>environment ... but I can only manipulate that by one day (unless
<span class="moz-txt-citetags">> </span>there's a syntax I don't know about).
<span class="moz-txt-citetags">> </span>
<span class="moz-txt-citetags">> </span>Thanks.
</pre>
</blockquote>
<pre wrap=""><!---->
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->
<div class="moz-txt-sig">--
Audio panton, cogito singularis,
</div></pre>
</blockquote>
Why not write the FPro routine to look at a declared variable instead
of @td and then load that variable to @td+"30"?<br>
<br>
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.<br>
<br>
Boaz<br>
</body>
</html>