time_t

[Charles Day]

On Wed, Jul 16, 2008 at 10:38 AM, Charles Day <cedayiv at gmail.com> 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).
>

I take that back... the capital of Tonga is normally UTC+13... during
daylight savings, they go to UTC+14!


>
> 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).
>
>
>> > Michael
>>
>> -derek
>>
>> --
>>       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>>       Member, MIT Student Information Processing Board  (SIPB)
>>       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>>       warlord at MIT.EDU                        PGP key available
>>
>
> -Charles
>