On Wed, Jul 16, 2008 at 10:59 AM, Phil Longstaff <[EMAIL PROTECTED]> wrote:
> Charles Day wrote: > > On Wed, Jul 16, 2008 at 9:47 AM, Derek Atkins <[EMAIL PROTECTED]> wrote: > > > >> Mike or Penny Novack <[EMAIL PROTECTED]> writes: > >> > >>> I would pay close attention to what Graham says here. > >>> > >>>> I didn't say that *all* timestamps were unnecessary, what I said was > >>>> that dates that are actually dates, and not times, are being stored > >>>> as times, and that this is incorrect. > >>>> > >>>> For an example, look at the date entered in a transaction. The UI > >>>> only allows you to choose a year, a month and a day, and because of > >>>> this, you should only store a year, a month and a day. > >>>> > >>> It is actually the case that (depending on financial policies) storing > >>> the actual time could present problems. > >>> > >>> For example -- the rule might be "process all credits for the given > >>> date before any debits for that date" --- or vice versa. If the > >>> programmer mistakenly used time stamps rather than dates, the sort > >>> would not give the expected results. > >> These rules can certainly vary from place to place, locale to locale, > >> or even person to person. Why force the issue? IF we let users > >> set the TimeOfDay (see bug #89439) then users could easily set the > >> intra-day ordering of transactions themselves. If GnuCash ONLY > >> stored a date then there would be NO WAY to set this. So I think > >> storing a timestamp really is more flexible. > >> > >> Having said that, I'll reiterate that I do still think there is a bug > >> here. I think that by DEFAULT GnuCash should store time stamps as > >> 1200 UTC on the day in question instead of what appears to ME to be > >> 0000 Local. Using 1200UTC would give a proper DAY computation in any > >> timezone even when converted to localtime (except perhaps if there > >> were a UTC+12 or UTC-12 timezone, at which point there's possibly a > >> fencepost issue). However I dont believe there is anyone who lives > >> *ON* the international date line. > >> > > > > I agree, 1200UTC would prevent time zones from shifting transactions to > > another day. That would be a better default than 0000 local. That could > work > > for default price times as well (see but 541970). > > > > P.S. I remember being in Tonga; the date line goes right through their > > country. There is an "International Date Line" hotel with the line > running > > right through the building (or so they tell the tourists). > > Hmmm... I thought the International Date Line was designed to *not* > intersect any land. That's why it's not straight. From Wikipedia, "The > date line circumvents the territory of Kiribati by swinging far to the > east, almost reaching the 150° meridian. > > In the South Pacific the dateline swings east such that Wallis and > Futuna, Fiji, Tonga, and New Zealand's Kermadec Islands have the same > date but Samoa is one day earlier." > It seems that the King of Tonga wished for his country to be "first in time": http://www.tongatapu.net.to/tonga/homeland/timebegins.htm > > Phil > > _______________________________________________ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
