Frequently Asked Questions
How does time simulation work?
Whether you running a simple monolithic application directly on the console of a machine or deploying a multi-tiered web-distributed application is irrelevant to the use of Time Simulator. In either case, or all those in-between, there is a named application (or set of applications) that when they need to get the time, they will make a system call or access another application that makes the system call. It is at that point that our software comes into play and delivers back to the application whichever virtual date is set. By being a virtualization layer between all applications and the system Kernel we are able to guarantee completely that any named application (or set of applications) will see the desired virtual date.
What’s the most efficient way to make Terminal Services clients see their local time instead of the server’s time?
You can set up one group of users per time zone, and put those groups on Time Simulator. Each group can be given a time offset from the server’s time, and can be automatically loaded by Time Simulator during system initialization. Changes to group membership in the OS account database are automatically reflected into Time Simulator and take effect the next time the affected users log on. Groups, as well users, can be added to or removed from Time Simulator through flexible and comprehensive utilities without affecting the other groups and users being served by Time Simulator. Those changes are effective immediately.
How does Time Simulator support roaming users that can connect to a Terminal Server from different time zones over a short period of time?
Roaming users that cannot get the correct local time through time-zone-based group membership because of their frequent time zone crossing can create their own virtual clock by using the command “tmuser -a -h [-m ]” after logging on. Their new virtual clock will override the group virtual clock they would normally use. In order to allow users to set their own clock, the utility tmuser_setup must have been run by an administrator. This virtual clock will last until a system reboot or it is manually removed by the user or an administrator.
Will other users on the same system see “my” virtual date and time and get confused?
No. Only the processes (and their descendant children) belonging to a user under Time Simulator will see the virtual date and time set for that particular user.
Why use Time Simulator and not just reset the system clock?
Productivity is boosted since you are not limited to one clock. Time Simulator also avoids single threaded testing, time-bombed programs and expired accounts! Re-setting the hardware clock forward will affect ALL programs trying to see the system’s clock, including the password program and software with expiration dates. Time Simulator allows users to see a virtual time while keeping the system clock to the present time. Time Simulator addresses time-bombed programs with its exclusion list. Any programs listed on the exclusion list will not see the virtual clock but rather will continue see the system date and time.
Will Time Simulator cause file timestamps to be updated to the virtual date and time? I am worried about my backups and system logging.
Unlike resetting the system clock, Time Simulator is safe and transparent to the file system. The file system still sees the current date and time and will update the file timestamps accordingly by default.
Can I have different programs see different virtual dates and times on the same system?
Absolutely. For example, a clock can be setup for each user so that they see their respective time zone.
My session and job can create child processes. Will the child processes also see the virtual date and time set by their parent process?
Yes. The scope of the virtual date and time is visible to the process that activates Time Simulator and all its descendant children processes.
My batch job streams another job within it. Will the nested job also see the virtual date and time set by the top-level job?
The nested job is NOT a child process of the top-level job, so by default it will not be affected by the virtual date and time. However, if virtual date and time is desired, you can: a) set a flag to cause the job to “inherit” it from the streaming job or session, b) use the Logon Automation feature, or c) simply insert a Time Simulator call in the nested job.
Other than application testing, what else can I use Time Simulator for?
Time Simulator can be used for training. For example, you can use the time virtualization tool to simulate the exact environment for month-end or quarter-end processing. It can be used to redo certain date and time-sensitive operations. Let’s say you missed quarter-end processing due to a hardware problem. Now, three days later, you can use the time simulation tool to regenerate the quarter-end report as if it were running on that exact date and time. Users in Japan can generate reports in their local time with Time Simulator on a system located in the United States. The possibilities are endless.
How do I avoid the Active Directory aka Kerberos “time-skew” issue with forward date testing?
In a network environment where secure logins are used, such as with Microsoft’s Active Directory, Novell’s eDirectory, or Sun Microsystems’ Sun One directory services, users login in with a time-based ticketing system through Kerberos, a network authentication protocol. One of the procedures employed by the Kerberos process to maintain network security is the hard requirement that any machine that participates in the network must have its system clock synchronized to be no more than five minutes different than the Domain Controller’s time. This clock synchronization is necessary to prevent an attacker from using an old authenticator to masquerade as a valid user. The exclusion feature in Time Simulator overcomes this issue by allowing the Kerberos login’s dynamically linked libraries and executables to run under the valid system time, so that all access tokens are requested with the correct time. This process, combined with Time Simulator’s file date-stamping (using real-time variables), ensures that all backups function correctly, file replication services run without disruption, and all machines running Time Simulator can freely participate in the secure network.
Will Time Simulator work for my Web-based application?
This time simulation technology is currently being utilized by thousands of companies worldwide to test changes to their date-sensitive business logic. Many of these have web based applications in which a time virtualization tool has been implemented. Whether it’s Web Sphere, Tibco, SAP, Oracle, People Soft, AJAX, or any other Web Based application / Web Front End, the Time Simulator software will provide the same benefits as if running on a Client Server Application.
Thanks to time simulation, time virtualization and time automation, a single application can now access and run under different virtual times.