multiple timezone support

We currently have a 9.40FC4 instance running on Solaris 9 set to GMT timezone. My company is looking to host a copy of our database but running within Eastern Standard Time i.e 5 hour behind the UK. We do not want to customise the application so handle timezone adjustments. Is is possible to have 2 IDS instances on the same server but configured so that dates and times on the other instance are within another timezone? I have been looking at Solaris 10 "containers" as another option but am not sure whether that supports multiple timezones either. Any advice would be appreciated.

"DAVID FORTUNE" <david.fortune@ingenico.co.uk> wrote on 05/17/2005 11:09:44 AM: > We currently have a 9.40FC4 instance running on Solaris 9 set to GMTtimezone. > > My company is looking to host a copy of our database but running > within Eastern Standard Time i.e 5 hour behind the UK. We do not > want to customise the application so handle timezone adjustments. > > Is is possible to have 2 IDS instances on the same server but > configured so that dates and times on the other instance are within > another timezone? > > I have been looking at Solaris 10 "containers" as another option but > am not sure whether that supports multiple timezones either. > > Any advice would be appreciated. Be careful. Yes - it's trivial to do, at least in principle. You do, however, have to be very, very careful! The trivial answer is that you start each server with the appropriate value of TZ set in the environment of the server when it is started. Presumably, this would be TZ=GMT0BST (or some more complex value which tells the system when the time zone switches from GMT (aka UTC) to BST because the rules are different in the USA from in Europe, even before the US Congress adds a month to either end of Daylight Saving Time), and TZ=EST5EDT. Personally, my systems all run with TZ=UTC0 - no switch between winter and summer time. The hard parts are (a) understanding what this does, and (b) making sure it happens totally consistently. a. The server evaluates CURRENT in the context of its time zone. Regardless of the value set by the client and sent to the server at connect time, the server uses its own TZ value when evaluating CURRENT. It indirectly affects TODAY, too - the date boundaries are determined by the server time zone. b. My session from the IBM Data Management Technical Conference last year 'G08: Is Your DBA Paranoid Enough?', aka 'The Paranoid DBA', shows how to ensure that your server is started uniformly. You should be able to find the presentation at various local IUG web sites, hosted by the IIUG at http://www.iiug.org/ - I've given it to user groups in Southern California, Kansas, and Seattle (Seattle is most recent, and hence most up to date - and also by far the longest; the presentation, in all versions, has extensive 'speaker notes' which provide a lot of information). Fundamentally, you have a single script that is always used to start each server, and that script always set the entire environment to a known value. This prevents your system administrators in Singapore or California from screwing up your users in New York or London by accidentally setting the server time zone to Pacific time or Singapore time. You do not need Solaris 10 zones to achieve this - and would be well advised to stay clear of them (Solaris 10 zones) until we've certified that IDS will work with them. There are a number of system calls that processes running in a zone are not allowed to make, and IDS makes some of those calls - caveat lector. Note that if you have people working in California as well as New York (or anywhere else in the US/Eastern time zone) and accessing the same database, you will need to worry about time zones. -- Jonathan Leffler (jleffler@us.ibm.com) STSM, Informix Database Engineering, IBM Information Management Division 4100 Bohannon Drive, Menlo Park, CA 94025 Tel: +1 650-926-6921 Tie-Line: 630-6921 "I don't suffer from insanity; I enjoy every minute of it!"