L

[Matthew Vanecek]

On Sat, 2003-08-02 at 13:54, Derek Atkins wrote:
> linas at linas.org (Linas Vepstas) writes:
> 
> > > Do y'all think that we should worry about that?  As far as I can tell,
> > > the data is stored properly in the database in all cases--it appears
> > > that it is just the presentation that is messed up. Opinions?
> > 
> > I'm not too concerned, except that the the gmt vs not gmt thing
> > should be clarified & fixed.
> 
> Agreed..
> 
> > I figure that with multiple users, different users might be in 
> > different timezones, so each user should see times in thier own
> > local timezone. 
> 
> IMHO, all dates should be stored in GMT and presented to local time
> for the viewer.  I.e., the user works in local time, the data is
> stored in GMT.  That the XML backend is adding a timezone is, IMHO, a
> bug that should be fixed.
> 

I agree with Linas.  Users will want to see stuff presented to them in
local time.  I personally want my data *stored* in local time, too,
which is how the engine currently gives it to the backend from the UI. 
The difference between the file and the postgres backend is that the
file backend actually stores the time zone information with the
timestamp, where the postgres backend doesn't. *That* is the bug, in the
postgres backend.

> As for postgres, I do not believe you need to (or should) change the
> column definition.  I think you should just store the timestamp in
> GMT, and read it back in as GMT.  We just need to figure out where the
> proper conversions are/should be done between GMT and localtime, but
> IMHO the backend should store in GMT.

GMT is overrated.  Given a time zone, you can convert any timestamp to
any other time zone. The gnc_iso8601_to_timespec_local() does that part
quite well.  This should make storing in GMT irrelevant.  However, the
scope of work to remove all time zone generations outside of your
conversion routines seems rather monumental, *considering the other
current priorities*.  You have to consider all the mktime, localtime,
etc., calls distributed throughout the code that use locally-defined
time zone information.  I'm not saying it *can't* be done--I'm saying 1)
it shouldn't be done now (if at all), and 2) it's really not worth the
effort, since the current implementation works so well.  The only bug is
that the backends do not all store the same data (file backend stores
w/time zone, PG backend stores w/o time zone).

My question in general was not *whether* the PG backend should be
changed. Rather, I'm more concerned about whether an upgrade path should
be provided.  Linas indicates yes, and since that's the direction I was
leaning already....

My next question is, during the upgrade path, should I rely on
Postgresql extensions to SQL, or use (as close to as possible)
SQL99-compliant SQL only.  Some of the Postgresql extensions make the
upgrade a bit easier, so I'm leaning that direction--especially since
it's the *postgres* backend. ;)

-- 
Matthew Vanecek
perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
********************************************************************************
For 93 million miles, there is nothing between the sun and my shadow except me.
I'm always getting in the way of something...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : /pipermail/attachments/20030803/fd4f84d5/attachment.bin