DST Roll-Forward date testing

[Keith Brister]

My application's manager wants me to set the date forward on an HP-UX vPar to test the DST patches (Java, HP-UX, Oracle, and Oracle ERP) that we have applied.

Is it possible to set the date forward for testing then set it back to the current date without problems?

[Tim Nelson · Accepted solution]

Going forward is usually ok.

Going back is a different story.

Depending on the applications, i.e. those that might have logic for checking validity of transactions, it is safest to stop the applications before moving time backward. Even better, reboot server to move back.

Just like Y2K testing, deja vu.

[George Liu_4]

It is a very bad idea to test on any product system.
Sure you can set the date to any day but the database may have some big issues.

[A. Clay Stephenson]

Note that it is a very bad idea to set the time backwards --- especially on a production box. I would only do this in a test environment -- and even then -- I would have a good backup and restore after setting the time backwards. The problem is that you will have timestamps that are in the future in some of your application data, database data, and file timestamps. This can wreak havoc with makefiles as the dependencies no longer make sense. You also have a situation where database transaction number 1000 occurs before transaction number 999. With the exception of Java testing (and it shouldn't be too hard to write a Jave time function test), the attached Perl script will test essentially everything except "homegrown" date routines --- and you shouldn't be using them anyhow. Because it uses the same underlying libC date routines that all UNIX programs should be using, if it works, the system works. There is no need to make any system time changes and it will display the exact second before and after each time transition. It can even test multiple TZ settings.

TZ=CST6CDT dst.pl -y 2007
TZ=EST5EDT dst.pl

Invoke as "dst.pl -u" for full usage.

[Keith Brister]

The box is a test system and the database can be discarded, if necessary, after the test.

My main concern is that the HP-UX operating system is stable after the date is set back. I have concerns that it would not be, but I am looking for someone more experienced that could confirm or dispute that.

Clay, thanks for the script.

[Bill Hassell]

> My main concern is that the HP-UX operating system is stable after the date is set back. I have concerns that it would not be, but I am looking for someone more experienced that could confirm or dispute that.

You are reading far too much into the impact of the patch. HP-UX knows nothing about timezones and daylight saving changes. HP-UX keeps only one time: UTC (aka, GMT) and it never changes froward or backward. Instead, each process inherits a timezone variable called TZ and this allows the classic Unix library time routines to adjust the time value automatically. You have more than two dozen timezones and daylight saving rules in effect at the same time on your system. Every year, politicians in various countries change things around and all that is needed for HP-UX is a modified tztab file. You can eve create your own personal timezone with your own rules for daylight saving.

Now that said, depending on the version of HP-UX you are running, you will want to reboot so that stored values can be refreshed. Java is a completely different story as it ignores the OS and invents it's own timekeeping. For more comprehensive details, see:

http://www.hp.com/go/dst

[mkmorrison]

You could give Time Machine a try. It's used in production by many financial and other companies and government entities that have date sensitive testing to perform. It supports many OS platforms, Oracle, SAP, Java, etc..and does not cause an issue with file time-stamps.

See:
http://h21007.www2.hp.com/portal/site/dspp/PAGE.template/page.catalog_product_detail?productId=65&jumpid=reg_R1002_USEN

or:
http://www.solution-soft.com/timemachine.shtml

[Keith Brister]

Sorry, I should have closed this long ago.