Glen -=20 you don't mention the platform, but on unix you can slowly adjust the = system clock (forward or back) using date -a. with this approach 1:30AM = should only happen once if that's the problem you need to avoid. can't tell = if that's the concern or not. this might be stating the obvious - but why not store the data using a relative time that does not fluctuate strangely twice a year? avoid = the problem. that said - i once worked with an application where out of order = timestamps would have been disastrous. the timestamps were localtime. the = solution there was to shut the application down for a couple hours each fall to = let all the messed up time between 1am and 2am go by un-noticed ;) AFAIK = they still do that. apps like this do happen... > -----Original Message----- > From: oracle-l-bounce@xxxxxxxxxxxxx > [mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of bernas, glen > Sent: Wednesday, November 03, 2004 2:10 PM > To: oracle-l@xxxxxxxxxxxxx > Subject: daylight saving -> global database >=20 >=20 > I have a global database and we have implemented data types=20 > "timestamp with > local time zones" > This works great, clients inform the database which time zone=20 > their in and > they get the correct time, >=20 > My problem is day light savings. Do we move the database=20 > time a back an > hour? We move the Host time clock back?? I don't really know=20 > what to do so > the timestamps don't get messed up. >=20 > Currently the server is off by an hour . and we don't know=20 > what to do or > know the implications of any of our actions. >=20 >=20 >=20 >=20 >=20 >=20 > ____________________________________________ >=20 > Glen Bernas > Database Administrator > EMC=B2 =09 > where information lives >=20 > Phone:=20 > Direct: (508) 249-2237 > Ext: 42237 >=20 >=20 >=20 >=20 > -- > //www.freelists.org/webpage/oracle-l >=20 -- //www.freelists.org/webpage/oracle-l