On Sat, 2003-08-02 at 13:54, Derek Atkins wrote: > [EMAIL PROTECTED] (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...
signature.asc
Description: This is a digitally signed message part
_______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
