time_t

Phil Longstaff plongstaff at rogers.com
Wed Jul 16 13:59:38 EDT 2008


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."

Phil



More information about the gnucash-devel mailing list