Xref: utzoo comp.databases:9576 comp.software-eng:5369 comp.infosystems:226
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!uwm.edu!spool.mu.edu!munnari.oz.au!metro!usage.csd.unsw.oz.au!sphinx!pta!yarra!melba.bby.oz.au!gnb
From: gnb@bby.oz.au (Gregory N. Bond)
Newsgroups: comp.databases,comp.software-eng,comp.infosystems
Subject: Re: TZ and INGRES (was: Re: Time Zones HELP!)
Message-ID: <1991Apr16.082104.11000@melba.bby.oz.au>
Date: 16 Apr 91 08:21:04 GMT
References: <1991Apr5.103756.18982@news.cs.indiana.edu>
	<1991Apr12.162244.5740@sun1.ruf.uni-freiburg.de>
Sender: usenet@melba.bby.oz.au (news READER id)
Organization: Burdett, Buckeridge and Young Ltd.
Lines: 22
In-Reply-To: heja@sun1.ruf.uni-freiburg.de's message of 12 Apr 91 16:22:44 GMT
Nntp-Posting-Host: leo-gw

It's even worse than this.

Ingres (5.xxx) on Suns does all the date conversions in the backend
(so no spanning timezones, now!)

And it uses a positively prehistoric version of the C library for
linking the backend, so doesn't use the zoneinfo stuff at all.  The
DST algorithms are compiled in and they are wrong.  We had problems
shifting out of DST where everything else in the place switched except
the Ingres database.  It pushed the whole system over for two weeks.

Braindead bloody system.  Reimplements curses, badly.  Reimplements
timezones, wrong.  Reimplements rsh protocols, wrong (and stores the
passwords in a reversible encryption, too, so anyone who has had
access to ingres source can read the password of any ingres user in the
world).

If it didn't cost so much, we'd change.
--
Gregory Bond, Burdett Buckeridge & Young Ltd, Melbourne, Australia
Internet: gnb@melba.bby.oz.au    non-MX: gnb%melba.bby.oz@uunet.uu.net
Uucp: {uunet,pyramid,ubc-cs,ukc,mcvax,prlb2,nttlab...}!munnari!melba.bby.oz!gnb