time_t

[Charles Day]

On Wed, Jul 16, 2008 at 10:59 AM, Phil Longstaff <plongstaff at rogers.com>
wrote:

> Charles Day wrote:
> > On Wed, Jul 16, 2008 at 9:47 AM, Derek Atkins <warlord at mit.edu> wrote:
> >
> >> Mike or Penny Novack <stepbystepfarm at mtdata.com> 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 at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>