Setting time zone in ASE

[robgaither]

Does anyone know if there is way to the set the datetime
used by the ASE server independently of the system time on
the host machine. Say I wanted to always use eastern
standard time but my failover machine was in pacific time or
central time. Is there a way to force ASE into a particular
timezone?

[Rob Verschoor]

The ASE wall clock time is by definition identical to the host's clock
time -- so the answer is no.

HTH,

Rob V.
-------------------------------------------------------------
Rob Verschoor

Certified Sybase Professional DBA for ASE 12.5/12.0/11.5/11.0
and Replication Server 12.5 / TeamSybase

Author of Sybase books (order online at www.sypron.nl/shop):
"Tips, Tricks & Recipes for Sybase ASE" (ASE 15 edition)
"The Complete Sybase ASE Quick Reference Guide"
"The Complete Sybase Replication Server Quick Reference Guide"

mailto:r...@YOUR.SPAM.sypron.nl.NOT.FOR.ME
http://www.sypron.nl
Sypron B.V., P.O.Box 10695, 2501HR Den Haag, The Netherlands
-------------------------------------------------------------

<rob gaither> wrote in message news:47626921.65b...@sybase.com...

[michael...@gmail.com]

On Dec 14, 1:23 pm, "Rob Verschoor"

<r...@DO.NOT.SPAM.sypron.nl.REMOVE.THIS.DECOY> wrote:
> The ASE wall clock time is by definition identical to the host's clock
> time -- so the answer is no.

Well - I suspect that ASE uses calls like localtime() to get the time.
If that is the case you could set the TZ environment variable in the
RUN_xxx file to override the timezone of the host:

[mpeppler@localhost ~]$ echo $TZ

[mpeppler@localhost ~]$ date
Fri Dec 14 13:26:07 EST 2007
[mpeppler@localhost ~]$ export TZ=PST
[mpeppler@localhost ~]$ date
Fri Dec 14 18:26:41 PST 2007
[mpeppler@localhost ~]$

Michael

[Mark A. Parsons]

If you're running on Unix/Linux take a look at the TZ (timezone) variable. TZ can be set at the server level (eg,
/etc/environment) or at the command line (eg, TZ=....).

I'm not in front of a Unix machine right now but you should be able to find quite a bit with a simple google on 'setting
unix timezone TZ'.

What you would do is modify the RUNserver file so that TZ is redefined prior to starting up the dataserver, eg:

==================== RUNserver
TZ=<some_other_time_zone>

${SYBASE}/${SYBASE_ASE}/bin/dataserver ....
==============================

You should even be able to test this at the command line:

echo $TZ # get your current TZ, if set
date # time under current TZ
TZ=<some_other_time_zone> # redefine TZ
date # time under new TZ

I've got a couple clients that use TZ to force the local dataserver to boot up thinking it's in a different timezone
(eg, hardware/OS in US East Coast timezone, ASE in London timezone).

If you have problems getting this to work just post back here ... I can try to dig up the details the next time I'm
logged into one of the clients' machines.

--------------------------

If you're running on Windows ... I don't know if/how you could accomplish the same thing.

--------------------------

Obviously (?) you'll need to look at setting up an NTP daemon (eg, xntpd/ntpdate/ntptrace/ntpq on AIX) to keep the
clocks in sync on multiple machines (eg, make sure they have the same MM:SS values).

[Derek Asirvadem]

On 2007-12-14 22:29:37 +1100, rob gaither said:

> Say I wanted to always use eastern
> standard time but my failover machine was in pacific time or
> central time.

Failover ? There is something seriously wrong with the logic in which
a Failover machine is set to a different TZ (although it is normally in
a different physical/geographic location) than the machine it is
failing over from. Having had experience with this, I would recommend
against ASE running in a TZ that is diff from the o/s (although other
have show you how). If you do change it, I would suggest extreme care
and fully testing of all failover scenarios (and the required extra
scripts resetting TZ). Considering all recovery issues, rather than a
few, you are better off with the Failover machine set to teh same TZ as
Production (otherwise you will have synchronisation issues elsewhere
... how do you keep Failover up-to-date ...) .

If it is not a true Failovr machine (eg. it is running UAT in a diff
TZ, and cuts over to Production_Secondary when Production fails), then
script the resetting of the o/s system time to the required Production
TZ. This will result in less scripting and checking.
--
Cheers
Derek
Senior Sybase DBA / Information Architect
Copyright Š 2007 Software Gems Pty Ltd
This is an inappropriate medium to confer tone, feeling, etc. None
intended, none taken.
"Patient, normalise thyself"

[Paul Dow]

Hi,

Generally speaking, under the covers, Unix kernels all run on the same
time - effectively UTC. Most of the wallclock time processing is done by the
run time libraries (e.f. see localtime(3C))

The value of raw "date/time" values from the OS is the elapsed seconds (and
possibly microseconds depending on the source) since 00:00 UTC on Jan 1 1970 (see
later of an example of how setting the timezone affects the display of date commands
and file system dates.

ASE's "wallclock" time will be whatever the wallclock time has been set
up to be in the timezone environment where ASE was started (there is usually the appropriate
timezone set up for the machine by default, but you can run an application in whatever timezone
you want by setting the TZ variable).

http://www.sybase.com/detail?id=1042106

has some handy info on daylight savings and ASE "times". If you are using getdate() in a distributed
timezone environment for the ASE servers (or perhaps even timezone distributed applications/users), then
you need to think carefully about what it is you really want the getdate() value for.

We plan on providing a built in to get hold of the ASE internal clock too in the not too distant future.

An example of how the dates for created files are affected by the timezone seen
by the ls(1) and date(1) programs follows:

uksol{pauld}6: touch timestamp_file
uksol{pauld}7: ls -l timestamp_file
-rw-r--r-- 1 pauld sybase 0 Jan 4 12:09 timestamp_file
uksol{pauld}8: date
Fri Jan 4 12:09:22 GMT 2008
uksol{pauld}9: setenv TZ US/Pacific
uksol{pauld}10: date
Fri Jan 4 04:09:46 PST 2008
uksol{pauld}11: ls -l timestamp_file
-rw-r--r-- 1 pauld sybase 0 Jan 4 04:09 timestamp_file
-------------........... note the change
uksol{pauld}12: setenv TZ GMT
uksol{pauld}13: date
Fri Jan 4 12:10:09 GMT 2008
uksol{pauld}14: ls -l timestamp_file
-rw-r--r-- 1 pauld sybase 0 Jan 4 12:09 timestamp_file
uksol{pauld}15:

- Paul

[Bret Halford]

Just as a side note, as of 12.5.3, there is a new built-in function getutcdate().

I personally think it is a good idea to set the server up to run on universal coordinated
time and make the clients responsible for any conversions to their local time zones,
daylight savings time schemes, etc.

-bret