Quoting Charles Day <[EMAIL PROTECTED]>:
>> > I believe several users have expressed that they do not want a time
>> written
>> > to their data file if they never actually entered one. That's one of the
>> > things I am proposing to support with this proposal. Saving defaulted
>> > transaction times would mean that when you read the file back in, you
>> > wouldn't know which times were user-entered and which times were
>> defaulted.
>>
>> Here's where I need to disagree. I'd like to see as little change
>> to the data file format as possible!
>>
>> Right now we're storing an ISO Date-Time string. We should continue
>> to do so, even in the cases where the user did NOT input an actual
>> "time".
>>
>> I really think that data file compatibility is also important.
>>
>> Personally I'm willing to forego any time zone support at all and just
>> always use/display GMT dates. But we can still store a timestamp and
>> ignore the time portion.
>>
>
> How would we know which times were user-entered and which times were
> defaulted? That's the only issue I have with keeping the file format
> unchanged. If we must store a posting timestamp in the data file, does
> Nathan's idea of saving a flag with each transaction appeal to you?
Does it really matter?
First, we're assuming that we ARE going to implement that feature,
which we don't necessarily need to.
Second, I think it's perfectly fine to choose a default time regarless.
Third, if we're just using the "time" to allow sorting of transactions
within a day, I don't think we need to store a timezone either. We
just use GMT and let the user choose a time other than the default
(which I still think should just be 1200).
As for the users who "dont want a time in their datafile", I'm perfectly
happy to ignore that "request". They are absolutely correct that the
UI (register, reports, etc) MUST NOT behave differently when the user
changes a timezone, but I see no reason to support a requirement that
the data file NOT contain a time.
Having said all that, we COULD put a flag in the KVP of the transaction
to flag that the time was entered by the user.
> If we don't know which times are user-entered and which are defaulted, then
> the user's preference for (6) now becomes a permanent choice, and that
> situation seems an awfully lot like forcing "date only" users to pick
> default transaction times. If they wanted to change the preference later, it
> could only affect future entries; we wouldn't be able to go through the
> existing transactions and adjust their default times, because we wouldn't
> know which transactions had been defaulted.
I'm happy to forego #6 completely. I'm also happy to have it only
affect "new" transactions, which means changing it has no effect
on existing transactions... Which is just fine... Which would
mean that we STILL dont need to store that information.
Note, however, that the Book Closing code does make an assumption about
the timestamps of both closing transactions and real transactions
to determine when the books have already been closed (so it doesn't
re-close them).
> -Charles
-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
[EMAIL PROTECTED] PGP key available
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
